1 



11 



(19) 




Europaisches Patentamt 
European Patent Office 
Olfice europeen des brevets 








(n) 



EP 0 917 149 A2 



(12) 



EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

19,05.1999 Bulletin 1999/20 

(21) Application number: 98308532.5 

(22) Date of filing: 19.10.1998 



(51) Intel e : G11B 27/10, G11B 27/32, 

G11B 27/034, G11B 20/12, 
G11B 27/34 
// H04N5/85 



(84) Designated Contracting States: 


(71) Applicant: SONY CORPORATION 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Tokyo 141 (JP) 


MC NL PT SE 




Designated Extension States: 


(72) Inventors: 


AL LT LV MK RO SI 


• Hamada, Toshiya 




Shinagawa-ku, Tokyo (JP) 


(30) Priority: 21.10,1997 JP 288180/97 


• Fujinami, Yasushi 


30.04.1998 JP 120389/98 


Shinagawa-ku, Tokyo (JP) 


27.02.1998 JP 46857/98 


■• 


27.02.1998 JP 46858/98 


(74) Representative: 


21.10.1997 JP 288181/97 


Robinson, Nigel Alexander Julian et al 


30.04.1998 JP 120391/98 


D. Young & Co., 




21 New Fetter Lane 




London EC4A 1 DA (GB) 



(54) Information processing apparatus, information processing method, presentation medium 
and recording medium 



(57) A system for improving the ease of editing in a 
recordable optical disk system is described formed ot a 
first control means for controlling a plurality of pieces of 



data on a 1 -on-1 basis; a second control means for con- 
trolling any arbitrary number of said first control means; 
and a third control means for controlling any arbitrary 
range in said second control means.: 
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Description 

[0001] In general, the present invention relates to an 
information processing apparatus, an information 
processing method, a presentation medium and a re- s 
cording medium. More particularly, the present inven- 
tion relates to an information processing apparatus, an 
information processing method, a presentation medium 
and a recording medium that allow editing to be carried 
out more easily. 10 
[0002] It is possible to properly edit video and audio 
data recorded in a recording medium such as a disc as 
required. In editing work, typically, a range of part of a 
piece of video data is joined to a part of other video data 
or a range of part of video data is erased. *5 
[0003] When such traditional work to edit data is car- 
ried out, however, it is the data itself that is linked or 
erased, giving rise to a problem that it takes labor and 
time to do editing including re-editing data which has 
once been edited. 20 
[0004] The present invention addresses the problem 
described above to allow editing work to be carried out 
easily and speedily. 

[0005] An information processing apparatus accord- 
ing to one aspect of the present invention is character- 25 
ized in that the apparatus including: 

a first control means for controlling a plurality of ' 

pieces of data on a 1-on-1 basis; 

a second control means for controlling any arbitrary 30 

number of the first control means; and 

a third control means tor controlling any arbitrary 

range in the second control means. 

[0006] An information processing method according 35 
lo another aspect of present invention is characterized 
in that the method including: 

. a first control step of controlling a plurality of pieces 
of data on a 1 -on-1 basis; 40 
a second control, step of controlling any arbitrary 
number of control states at the first control steps; 
and 

a third control step of controlling a control state of 
any arbitrary range at the second control step. 45 

[0007] A presentation medium according to another 
aspect of the present invention is characterized in that 
the medium is used for presenting a~program for making, 
an information processing apparatus carry out process- so 
ing including: 

a first control step of controlling a plurality of pieces 
of data on a 1 -on-1 basis; 

a second control step of controlling any arbitrary ss 
number of control states at the first control steps; 
and 

a third control step of controlling a control state of 



any arbitrary range at the second control step. 

[0008] A recording medium used for recording data 
and control information for controlling the data accord^ 
ing to another aspect of the present invention is charac- 
terised in that the control information including: 

a first control means for controlling a plurality of 
pieces of data on a 1-on-1 basis; . 
a second control means for controlling any arbitrary 
number of the control first control means; 
arid a third control means for controlling any arbi- 
trary range in the second control means. 

[0009] In the information processing apparatus ac- 
cording to another aspect of the present invention, a plu- 
rality of pieces of data are controlled by first control 
means on a 1^on-1 basis and any arbitrary number of 
first control means are controlled by a second control 
means, any arbitrary range in which is controlled by a 
third control means. 

[0010] In the information processing method accord- 
ing to another aspect of the present invention and the 
presentation medium according to the present inven- 
tion, any arbitrary number of control states at first control 
steps are controlled at a second control step and a con- 
trol state of any arbitrary range at the second control 
step is controlled at a third control step. 
[0011] In the recording medium according to at least 
preferred embodiments of the present invention, as con- 
trol jnformatibn, first control means, a second control 
means and a third control means are recorded. 
[0012] Embodiments of the invention will now be de- 
scribed, by way of example only, with reference to the 
accompanying drawings in which: . 

Fig. 1 is an explanatory diagram used for describing 

an organization of directories; 

Fig. 2 is an explanatory diagram used for describing 

the structure of a VOLUME.TOC file; 

Fig. 3 is an explanatory diagram used for describing 

the structure of volume_in format ion ( ) ; 

Fig. 4 is an explanatory diagram used for describing 

the structure of volume_attribute ( ) ; 

Fig. 5 is an explanatory diagram used for describing 

the structure of resume ( ); 

Fig. 6 is an explanatory diagram used for describing 
the structure of vo!ume_rating ( ); 
Fig. 7 is an explanatory diagram used for describing 
the structure of write_protect ( ); 
Fig. 8 is an explanatory diagram used for describing 
the structure of playjprotect ( ); 
Fig. 9 is an explanatory diagram used for describing 
the structure of recordingjimer ( ); 
Fig. 10 is an explanatory diagram used for describ- 
ing the structure of text_block ( ); 
Fig. 11 is an explanatory diagram used for describ- 
ing the structure of language_set ( ); 
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Fig. 12 is an explanatory diagram used for describ- 
ing the structure of textjtem ( ); 
.Fig. 13 is an explanatory diagram used for describ- 
ing the structure of ALBUM. STR; 
Fig. 14 is an explanatory diagram used for describ- 
ing the structure of album ( ); 
Fig. 15 is an explanatory diagram used for describ- 
ing the structure of TITLE_###. VDR; 
Fig. 16 is an explanatory diagram used for describ- 
ing the structure of titie_info ( ); 
Fig. 17 is an explanatory diagram used for describ- 
ing the structure of ,PROGRAM_$$$.PGI; 
Fig. 18 is an explanatory diagram used for describ- 
ing the structure of program ( ); 
Fig. 19 is an explanatory diagram used for describ- 
ing the structure of playjist ( ); 
Fig. 20 is an explanatory diagram used for describ- 
ing the structure of play_item { ); 
Fig. 21 is an explanatory diagram used for describ- 
ing the structure of CHUNKGROUP_###.CGlT; 
Fig. 22 is an explanatory diagram used for describ- 
ing the structure ot chunk_connection_info ( ); 
Fig. 23 is an explanatory diagram used for describ- 
ing the structure ol chunk_arrangement_info ( );. 
Fig. 24 is an explanatory diagram used for describ- 
ing the structure of CHUNK_%%%.ABST; 
Fig. 25 is a block diagram showing a typical config- 
uration of an optical-disc apparatus to which one 
embodiment of the present invention is applied; 
Fig. 26 is an explanatory diagram used for describ- 
ing an organization of directories; 
Fig. 27 is an explanatory diagram used for describ- 
ing a logical organization of directories; 
Fig. 28 is an explanatory diagram used for describ- 
ing an offset; 

Fig. 29 is an explanatory diagram used for describ- 
ing an organization of directories; 
Fig. 30 is an explanatory diagram used for describ- 
ing an organization of directories; 
Fig. 31 is an explanatory diagram used for describ- 
ing a logical organization of directories; 
Fig. 32 is an explanatory diagram used for describ- 
ing an organization of directories; 
Fig. 33 is an explanatory diagram used for describ- 
ing an organization of directories; 
Fig. 34 is an explanatory diagram used for describ- 
ing a logical organization of directories; 
Fig. 35 is an explanatory diagram used for describ- 
ing a logical organization of directories; 
Fig. 36 is an explanatory diagram used for describ- 
ing file_type_id; 

Fig. 37 is an explanatory diagram used for describ- 
ing mark_type; 

Fig. 38 is an explanatory diagram used for describ- 
ing a chunk group; 

Fig. 39 is an explanatory diagram used for describ- 
ing a chunk group; 

Fig. 40 is an explanatory diagram used for describ- 
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ing file_type_id; 

Fig. 41 is an explanatory diagram; used for describ- 
ing chunk_sync_play_lf!ag; 

Fig. 42 is an explanatory diagram used for describ- 
ing originaLtime_count_type; 
Fig. 43 is an explanatory diagram used for describ- 
ing file_type_id; 

Fig. 44 is an explanatory diagram used for describ- 
ing infojype; 

Fig. 45. is an explanatory diagram used for describ- 
ing slot_unit_type; 

Fig. 46 is an explanatory diagram used for describ- 
ing file_type_id; 

Fig. 47 is an explanatory diagram used for describ- 
ing program_status; 

Fig. 48 shows a flowchart used for explaining 
processing to split a title; 

Fig. 49 is an explanatory diagram used for describ- 
ing hierarchical layers of a program, titles, chunk 
groups, chunks and streams; 
Fig. 50 shows a flowchart used for explaining 
processing to swap titles; 

Fig. 51 is an explanatory diagram used for describ- 
ing hierarchical layers of a program, titles, chunk 
groups, chunks and streams; 
Fig. 52 shows a flowchart used for explaining 
processing to delete a title; 

Fig. 53 is an explanatory diagram used for describ- 
ing processing to delete a title; 
Fig. 54 shows a flowchart used for explaining 
• processing to merge titles; 
Fig. 55 shows a flowchart used for explaining 
processing to set up an operation to play back a pro- 
gram; 

Fig. 56 is an explanatory diagram used for describ- 
ing hierarchical layers of a program, titles, chunk 
groups, chunks and streams; 
Fig. 57 shows a flowchart used for explaining 
processing to play back a program; 
Fig. 58 is an explanatory diagram used for describ- 
ing the configuration of a program; 
Fig. 59 is an explanatory diagram used for describ- 
ing the configuration of a play sequence; and 
Fig. 60 is an explanatory diagram used for describ- 
ing relations among a program, play sequences and 
play items. " 

[001 3] Before embodiments of the present invention 
are described, each means cited in claims of the patent 
in the specification is exemplified by a typical implemen- 
tation appended after the means by enclosing the im- 
plementation in parentheses in the following description 
of characteristics of the present invention Tn order to 
clarify a relation associating the means with the imple- 
mentation. It is needless to say, however, that the ap- 
pended implementation is not to intended to be con- 
strued in a limiting sense, that is, examples of the means 
are not limited to the appended implementation. . 



091 71 48 A2 I _> 



5 EP0 917 

[0014] An information processing apparatus accord- 
ing to at least a preferred embodiment is characterized 
in that the apparatus comprises: 

- 

a first control means (implemented typically by 5 
CHUNK_%%%%. ABST shown in Fig. 24) for con- 
trolling a plurality of pieces of data on a 1 -on-1 ba- 
sis; 

a second control means (implemented typically by 
CHUNKGROUP_###.CGIT shown in Fig. 21) lor 10 
controlling any arbitrary number of the first control 
means; and 

a third control means (implemented typically by 
TITLE_##ff.VDR shown in Fig. 15) for controlling 
any arbitrary range in the second. control means. is 

[0015] The description begins with an explanation of 
a layout of files on a recording medium provided by the 
present invention, which information is recorded into 
and played back from. Recorded on the recording me- 20 
dium, files shown in Fig. 1 are classified into 7 types 
listed below. 

. VOLUME.TOC 
ALBUM.STR 25 
PROGRAM_$$$.PGI 
TITLE_###.VDR 
CHUNKGROUP_@ @ @.CGIT 
CHUN K_%%%%. A BST 
■ CHUNK_%%%%.MPEG2 30 

* • 

[0016] The VOLUME.TOC and ALBUM.STR tiles are 
placed in a root directory. A directory named ■PRO- 
GRAM" is placed immediately below the root directory. 
The PROGRAM directory includes PROGRAM_$$$. 35 
PGI files where notation $$$ represents the number ol 
a program. By the same token, a directory named TITLE 
is placed immediately below the root directory. The TI- 
TLE directory includes TITLE_###.VDR files where no- 
tation ### represent the number of a title. Placed imme- *o 
diately below the root directory, a CHUNKGROUP di- 
rectory includes CHUNKGROUP_@ @ @.CGIT files 
where notation @@@ represents the number of a 
chunk group and a CHUNK directory includes 
CHUNK_%%%%.ABST files where notation %%%% 45 
represents the number of a chunk. 
[0017] Also placed immediately below the root direc- 
tory, an MPEGAV directory contains a plurality of sub- 
directories which each include CHUNK_%%%%. 
MPEG2 files where %%%% represents the number of so 
a chunk. 

[0018] Normally, one VOLUME.TOC file exists in the 
recording medium. In a recording medium with a special 
structure such as a recording medium with a ROM and 
RAM hybrid structure, however, a plurality of VOLUME. 55 
TOC files may exist. This VOLUME.TOC file is used for 
showing the property of the recording medium as a 
whole. 
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[0019] Fig. 2 is a diagram showing the structure of the. 
VOLUME.TOC file. As shown in the figure, file_type_id 
is placed at the head of the file to indicate that the file is 
a VOLUME.TOC tile. fiie_typejd is followed by 
volumejnformation () which is finally followed by 
text^block ( ). 

[0020] Fig. 3 is a diagram showing the structure of 
volumejnformation ( ). As shown in the figure, 
volume Jn formation ( ) comprises volume_attribute ( ), 
resume (.), volume_rating ( ), write_protect ( ), 
play_protect ( ) and recording_timer ( ). 
[0021] volume_attrfoute ( ) is an area used for record- 
ing attributes of the logical volume. Fig. 4 is a diagram 
showing a detailed structure of voIume_attribute ( ). As 
shown in the figure, volume_attribu1e ( ) includes 
title_playback_mode_flag and program_playback_ 
mode_flag. 

[0022] resume ( ) is an area used for recording infor- 
mation used in restoration of a state immediately prior 
to an eject operation at the time the recording medium 
is reinserted. Fig. 5 is a diagram showing a detailed 
structure of resume ( ). 

[0023] volume_rating ( ) shown in Fig. 3 is an area 
used for recording information used in implementation 
of age limitation of watchers/listeners of the volume as 
a whole in accordance with user ages and user catego- 
ries. Fig. 6 is a diagram showing a detailed structure of 
volume_rating ( ). 

[0024] write_protect ( ) shown in Fig. 3 is an area used 
for recording information used in limitation of operations 
to change and delete a title or a program. Fig. 7 is a 
diagram showing a detailed structure of write_protect 

0 . 

[0025] play_protect ( ) shown in Fig. 3 is an area used 
for recording information setting a playback enable func- 
tion or a playback disable function and limiting the 
number of playback operations for a title or a program 
recorded in the volume. Fig. 8 is a diagram showing a 
detailed structure of play_protect ( ). 
[0026] recordingjimer ( ) shown in Fig. 3 is an area 
used for recording information controlling a recording 
time. Fig. 9 is a diagram showing a detailed structure of 
record ing_timer ( ). 

[0027] Fig. 10 is a diagram showing a detailed struc- 
ture of text_block ( ) of the VOLUME.TOC file shown in 
Fig. 2. As shown in Fig. 10. text_block () includes 
language_sets ( ) and textjtems ( ). Figs. 11 and 12 
show detailed structures of language_set ( ) and 
text.item ( ) respectively. 

[0028] Normally, one ALBUM.STR file shown in Fig. 

1 exists in a recording medium. In a recording medium 
• with a special structure such as a recording medium with 

a ROM and RAM hybrid structure, however, a plurality 
of ALBUM.STR files may exist. The ALBUM.STR file is 
used for combining a plurality of recording media into a 
configuration that makes the recording media appear as 
if there were only a single recording medium. 
[0029] Fig. 13 is a diagram showing the structure of 
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the ALBUM.STR file. As shown in the figure, filejypejd 
is placed at the head of the file to indicate that the file is 
ALBUM.STR. filejypejd is followed by album ( ) which 
is finally followed by text J)lock ( ). 
[0030] album ( ) is an area used tor recording infor- 
mation used in handling a plurality ot volumes, that is, 
a plurality of recording media, as one integrated volume. 
Fig. 14 is a diagram showing a delailed structure ol al- 
bum ( ). 

[0031] As many TITLE_###.VDR files shown in Fig. 
1 as titles exist. A title refers to, for example, a musical 
selection in the case of a compact disc or a program in 
the case of a television broadcasting. Fig! 15 is a dia- 
gram showing the structure of a TITLE JMff.VDR file. 
As shown. in the figure, filejypejd is placed at the head 
of the file to indicate that the file is TITLE_###.VDR. 
filejypejd is followed by title_info ( ) which is finally 
followed by text_block ( ). Notation #.## is a string of 
characters representing the number of a title. 
[0032] title Jnlo ( ) is an area used for recording a start 
point and an end point of the title on a chunk group and 
other attributes of the title. Fig. 16 is a diagram showing 
a detailed structure of title Jnfo ( ). 
[0033] As many PROGRAM_$$$.PGI files shown in 
Fig. 1 as programs exist. A program comprises a plural- 
ity of cuts each specifying an area of a portion or all of 
a title. Cuts of a program are played back in a specified 
order. Fig. 17 is a diagram showing the structure ot a 
PROGRAM_$$$.PGI file. As shown in the figure, 
file_type_id is placed at the head of the file to indicate 
that the file is PROGRAM_$$$.PGI. filejypejd is fol- 
lowed by program ( ) which is finally lollowed by 
text jDlock ( ). Notation $$$ is a string of characters rep- 
resenting the number of a program. 
[0034] program ( ) is an area used for recording infor- 
mation required in an operation to collect necessary por- 
tions of titles and play back them without accomplishing 
irreversible editing of materials. Fig. 18 is a diagram 
showing a detailed structure of program ( ). 
[0035] program ( ) shown in Fig. 18 has one playjist. 
Fig. ig is a diagram showing details of playjist ( ). 
[0036] A plurality of playjtems ( ) are placed in 
playjist. Fig. 20 is a diagram showing details of 
playjtem ( ). 

[0037] As many CHUNKGROUP__@ ® O.CGIT files 
shown in Fig. 1 as many chunk groups exist. A chunk 
group is a data structure used for arranging a bit stream. 
When the user normally operates an apparatus for re- 
cording and playing back information into and from a re- 
cording medium such as a VDR (Video Disc Recorder), 
the user is not aware of the existence of this file. 
[0038] Fig. 21 is a diagram showing a 
CHUNKGROUP^® @@.CGIT file. As shown in the fig- 
ure, filejypejd is placed at the head of the file to indi- 
cate that the file is CHUNKGROUP_@@@.CGIT. 
filejypejd is followed by chunkgroupJime_base_ 
flags and chunkgroupJime_base_offset which are fol- 
lowed by chunk_connectk>n Jnfo ( ). Finally, chunk.. 
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cbnnectionjnfo ( ) is followed by text_block ( ). 
[0039] chunkgroupJime__baseJlags are flags each 
associated with a reference counter of a chunk group. 
chunkgroupJime_base_offset shows a start time of a 

s reference time axis of a chunk group. chunkgroup_ 
time_base_offset is a 32-bit value set in a counter which 
counts up at a frequency of 90kHz. criunk_connection_ 
inlo () is an area used for recording peculiar information 
such as a video switch-over point, and video and audio 

io synchronization. Fig. 22 is a diagram showing a detailed 
structure of chunk_connectionJnfo ( ). 
[0040] chunk^connection Jnfo ( ) includes as many 
loops of chunk_arrangement Jnfo ( ) as chunks pertain- 
ing to a chunk group. Fig. 23 is a diagram showing de- 

is tails of chunk_arrangementJnfo ( ). 

[0041] As many CHUNK_%%%%.ABST files shown 
in Fig. 1 as many chunks exist. A chunk is information 
file for a stream file. Fig. 24 is a diagram showing the 
structure of a CHUNK_%%%%.ABST file. As shown in 

20 the figure, filejypejd is placed at the head of the file 
to indicate that the.file is CHUNK_%%%%.ABST. 
[0042] The CHUNK_%%%%.MPEG2 file shown in 
Fig. 1 is a stream file. Unlike other files which are gen- 
erally used for storing information only, this file is used 

25 for storing an MPEG bit stream. 

[0043] Fig. 25 is a diagram showing a typical config- 
uration of an optical-disc apparatus for* recording and 
playing back information into and from an optical disc 
used as a recording medium including the files de- 

30 scribed above. In the optical-disc apparatus, a single op- 
tical head 2 is provided for a rewritable, optical disc 1. 
The optical head 2 is used for both reading out and writ- 
ing information from and into the optical disc 1 . 
[0044] After being demodulated in an RF & demodu- 

35 lation/modulation circuit 3, a bit stream read out by the 
optical head 2 from the optical disc 1 is subjected lo error 
correction in an ECC circuit 4 before being supplied to 
a read-out channel buffer 6 for absorbing a difference 
between a read -out rate and a decode- processing rate 

40 by way of a switch 5. An output of the read-out channel 
buffer 6 is supplied to a decoder 7. The read-out channel 
buffer 6 is designed so that a system controller 1 3 is 
capable of reading and writing the read-out channel 
buffer 6. 

45 [0045] A bit stream output by the 1 readout channel 
buffer 6 is decoded by the decoder 7 which outputs vid- 
eo and audio signals as results ol decoding. The video 
signal output by the decoder 7 is supplied to a synthesis 
circuit 8 to be synthesized therein with a video signal 

so generated by an OSD (On Screen Display) control cir- 
cuit 9. A result of the synthesis is output through an out- 
pul terminal PI to a display unit be displayed on the dis- 
play unit which is not shown in the figure. In the mean 
time, the audio signal generated by tr^e decoder 7 is out- 

55 put to a speaker through an output terminal P2 to be 
played back in the speaker which is also not shown in 
the figure. 

[0046] On the other hand, a video signal input from 
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an input terminal P3 and an audio signal input from an 
input terminal P4 are encoded by an encoder 10 before 
being supplied to a write-in channel buffer 1 1 for absorb- 
. ing. a difference between an encode-processing rate 
and a write-in rate. The write-in channel buffer 11 is also s 
designed so that the system controller 13 is capable of 
reading and writing the write-in channel buffer 11. 
[0047] Data slored in the write-in channel buffer 1 1 is 
read out from the write-in channel buffer 11 and supplied 
to the ECC circuit 4 by way of the switch 5. In the ECC 10 
circuit 4, an error correction code is added to the data 
before the data is supplied to the RF & demodulation/ 
modulation circuit 3 to be modulated thereby. A signal, 
strictly, speaking, an RF signal, outpul by the RF & de- 
modulation/modulation circuit 3 is recorded onto the op- *5 
tical disc 1 by the optical head 2. 

[0048] An address detecting circuit 12 detects infor- 
mation on an address on a track on an optical disc 1 
subjected to a recording or playback operation. The sys- 
tem controller 13 controls operations of components 20 
composing the optical-disc apparatus. The system con- 
troller 13 comprises a CPU 21 for executing various 
kinds of control, a ROM unit 22 for storing information 
such as processing programs to be executed by the 
CPU 21 , a RAM unit 23 for temporarily storing informa- 25 
tion such as data obtained as a result in the course of 
processing carried out by the CPU 21 and a RAM unit 
24 for storing a variety of information files to be recorded 
or played back into or from the optical disc 1 . The CPU 
21 finely adjusts the position of the optical head 2 on the 30 
basis of a result of detection output by the address de- 
tecting circuit 12. The CPU 21 also controls switching- 
over operations of the switch 5. Composed of a variety 
of switches and a variety of buttons, an input unit 14 is 
operated by the user for entering a variety of commands 35 
to the optical-disc apparatus. 

[0049] Next, a basic operation to read in data from an 
information file is explained. In an operation to read in 
data from the VOLUME. TOC information file, for exam- 
ple, the CPU 21 employed in the system controller 13 *o 
first confirms the physical address at which the VOL- 
UME. TOC file is recorded in the optical disc 1 and the 
length of the file by using a file-system operation instruc- 
_ tion included in a processing program in advance. Then, 
the CPU 21 moves the optical head 2 to a read-out po- 45 
sition on the basis of information on the address of the 
VOLUME.TOC file. Subsequently, the CPU 21 sets the 
optical head 2, the RF & demodulation/modulation cir- 
cuit 3 and the ECC circuil 4 in a read-out mode and po- 
sitions the switch 5 on the side of the read-out channel so 
buffer 6. Furthermore, the CPU 21 .finely adjusts the po- ' 
sition of the optical head 2 before starting a read-out 
operation by using the optical head 2. In the read-out 
operation, contents of the VOLUME.TOC file are read 
out by the optical head 2 and demodulated by the RF & 55 
demodulation/modulation circuit 3. The output of the RF 
& demodulation/modulation circuit 3 is subjected to error 
correction in the ECC 4 before being stored in the read- 
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out channel buffer 6. 

[0050] When the amount of data stored in the read- 
out channel buffer 6 becomes equal to or exceeds the 
size of the VOLUME.TOC file, the CPU 21 halts the 
read-out operation. Later on, the CPU 21 reads out the 
data stored in the read-out channel buffer 6 and stores 
the data in the RAM unit 24. 

[0051] Next, a basic operation to write dala into an 
information file is explained by taking the VOLUME TOC 
information file as an example. First of all, the CPU 21 
searches the file system, that is, the optical disc 1 , for a 
free area having a size equal to or larger than a VOL- 
UME.TOC file, into which data is to be written, and con- 
firms the address of the free area by using a file-system 
• operation instruction included in a processing program 
in advance. 

[0052] Then, the CPU 21 transfers the VOLUME.TOC 
file prepared in the RAM unit 24 and to be newly written 
into the optical disc 1 to the write-in channel buffer 11 .. 
The CPU 21 then moves the optical head 2 to a write- 
in position on the basis of information on the address of. 
the VOL UME.TOC file. Subsequently, the CPU 21 sets 
the optical head 2, the RF & demodulation/modulation 
circuit 3 and the ECC circuit 4 in a write-in mode and 
positions the switch 5 on the side of the write-in channel 
buffer 11. Furthermore, the CPU 21 finely adjusts the 
position of the optical head 2 before starting a write-in 
operation by using the optical head 2. 
[0053] In the write-in operation, the newly prepared 
contents of the VOLUME.TOC file are read out from the. 
write-in channel buffer 11 and supplied to the ECC cir- 
cuit 4 by way of the switch 5. In the ECC circuit 4, an 
error correction code is added to the contents before 
modulation by the RF & demodulation/modulation circuit 
3. A signal output by the RF & demodulation/modulation 
circuil 3 is recorded into the optical disc 1 by the optical 
head 2. When the amount of data read out from the 
write-in channel buffer 11 andTecorded into the optical 
disc 1 becomes equal to or exceeds the size of the VOL- 
UME.TOC file, the CPU 21 harts the write-in operation. 
[0054] Finally, the CPU 21 rewrites a pointer pointing 
to* the VOLUME.TOC file on the file system, that is, the 
optical disc 1 , so as to make the pointer point to the new- 
ly written position by using a file-system operation in- 
struction included in the processing program in ad- 
vance. 

• 

[0055] * Next, a basic operation to play back a stream 
is explained by taking a CHUNK_0001.MPEG2 file 
shown in Fig. 1 as an example. First of all, the CPU 21 
employed in the system controller 13 confirms the phys- 
ical address at which the CHUNK_0001.MPEG2 file is 
recorded in the optical disc 21 and the length of the file 
by using a file-system operation instruction Included in 
a processing program in advance. Then, the CPU 21 
moves the optical head 2 to a read-out position on the 
basis of information on the address of the CHUNK_. 
0001.MPEG2 file. Subsequently, the CPU 21 sets the 
optical head 2. the RF & demodulation/modulation cir- 
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cuit 3 and the ECC circuit 4 in a read-out mode and po- 
sitions the switch 5 on the side of the read-out channel 
buffer 6. Furthermore, the CPU 21 finely adjusts the po- 
sition of the optical head 2 before starting a read-out 
operation by using the optical head 2. 
[0056] in the read-out operation; contents of the 
CHUNK_0001.MPEG2 file read out by.the optical head 
2 are stored in the read-out channel buffer 6 through the 
RF & demodulation/modulation circuit 3, the ECC circuit 

4 and the switch 5. The data stored in the read-out chan- 
nel buffer 6 is output to the decoder 7 to be decoded by 
the decoder 7 which outputs video and audio signals as 
results of decoding. The audio signal generated by the 
decoder 7 is output to the output terminal P2. In .the 
mean time, the video signal output by the decoder 7 is 
supplied to the output terminal P1 through the synthesis 
circuit 8. 

[0057] When the. amount of data read out from the op- 
tical disc 1 and decoded by the decoder 7 to be finally 
displayed becomes equal to the size of the 
CHUNK_0001 .MPEG2 or when an instruction to halt the 
read-out operation is received Irom the input unit 14, the 
CPU 21 stops the read-out and decode processing. 
[0058] Next, a basic operation to record a stream into 
an information file is explained by taking the 
CHUNK_000 1.MPEG2 information file as an example. 
First of all, the CPU 21 searches the file system, that is, 
the optical disc 1, for a free area having a size equal to 
or larger than the CHUNKJX501 . MPEG2 file, into which 
a stream is to be written, and confirms the address of 
the free area by using a file-system operation instruction 
included in a processing program in advance. 
[0059] A video signal input from the input terminal P3 
and an audio signal input from the input terminal. P4 are 
encoded by an encoder 10 before being supplied to the 
write-in channel buffer 11. The CPU 21 then moves the 
optical head 2 to a write-in position on the basis of in- 
formation on the address of the CHUNK_0001 MPEG2 
file. Subsequently, the CPU 21 sets the optical head 2, 
the RF & demodulation/modulation circuit 3 and the 
ECC circuit 4 in a write-in mode and positions the switch 

5 on the side of the write-in channel buffer 11. Further- 
more, the CPU 21 finely adjusts the position of the op- 
tical head 2 before starting a write-in operation by using 
the optical head 2. In the write-in operation, the newly 

• prepared contents of the CHUNK_0001 .MPEG2 file are 
read out from the write-in channel buffer 11 and supplied 
to optical head 2 by way of the switch 5, the ECC circuit 
4 and the RF & dernddulat ion/modulation circuit 3. A sig- 
nal output by the RF & demodulation/modulation circuit 
3 is recorded into the optical disc 1 by the optical head 2. 
[0060] When the amount of data read out from the 
write-in channel buffer 11 and recorded into the optical 
disc 1 becomes equal to the size of the 
CHUNK_0001 .MPEG2 or when an instruction to hart the 
write-in operation is received from the input unit 14, the 
CPU 21 stops the write-in processing. Finally, the CPU 
21 rewrites a pointer pointing to the CHUNK_ 
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0001.MPEG2 file on the file system, that is. the optical 
disc 1 , so as to make the pointer point to the newly writ- 
ten position by using a file-system operation instruction 
included in the processing program in advance. 

5 [0061] Assume that information and stream files 
shown in Fig. 26 have been recorded in the optical disc 
1. In this example, the optical disc 1 includes a file 
named PROGRAM 001. PGI for storing a program. In 
addition, the optical disc 1 also includes three title files 

10 named TITLE_001 VDR, TITLE_002.VDR and 
TITLE_003.V.DR respectively. 

[0062] Furthermore, the optical disc 1 also includes 
two chunk-group information files named CHUNK- 
GROUP_001.CGIT and CHUNKGROUP_002.CGIT 

75 On the top 'of that, the optical disc 1 includes three 
stream files named CHUNK_0001 .MPEG2, CHUNK_ 
0011.MPEG2 and CHUNKJ)012.MPEG2 as well as 
three information files named CHUNK_0001.ABST, 
CHUNK_0011.ABST and CHUNK_0012.ABST associ- 

20 ated with the CHUNK_0001 MPEG2. CHUNK_ 
0011.MPEG2 and CHUNK_0012.MPEG2 files respec- 
tively. 

[0063] Fig. 27 is a diagram showing the logical struc- 
ture of the optical disc 1 containing the information and 

25 stream files shown in Fig. 26. In this example, the chunk 
information files named CHUNK_0001 . ABST, CHUNK_ 
0011. ABST and CHUNK_0012.ABST specify the 
CHUNK_0001.MPEG2, CHUNK_0011.MPEG2 and 
CHUNK_0012.MPEG2 stream files respectively. To put 

30 it concretely, in a chunk_fite_id field of each of the 
CHUNK_%%%%.ABST-files shown in Fig. 24, the file 
ID of the associated stream file is specified. 
[0064] In addition, in this example; the chunk-group 
information file named CHUNKGROUP_001.CGIT 

as specifies the chunk information file named CHUNK_ 
0001. ABST whereas the chunk-group information file 
named CHUNKGROUP_002.CGIT specifies the chunk 
information files named CHUNK^OOH.ABST and 
CHUNK_0012.ABST. To put it concretely, in a 

<to chunk_info_file_id field of chunk_arrangement_info ( ) 
shown in Fig. 23, a file ID of chunk information is spec- 
ified. This chunk_arrangement_info ( ) is included in a 
chunk group information file. As many chunky 
arrangement_infos ( ) as chunks pertaining to a chunk 

45 group exist in the data structure. It should be noted that 
chunk_arrangement_info ( ) shown in Fig. 23 is de- 
scribed in chunk_connection_info ( ) shown in Fig.~22 
and this chunk_connection_info is described in the 
CHUNKGROUP_ ###.CGIT file shown in Fig. 21. 

so [0065] There is only one chunk_arrangement_jnfo ( ) 
in CHUNKGROUP_001. The chunk_info_fi!e_id fietd of 
this chunk_arrangement_info ( ) specifies CHUNK_ 
0001. On the other hand, there are two 
chunk_arrangement_infos ( ) in CHUNKGROUPJ)02. 

55 The chunk_info_fileJd fields of these chunk_ 
arrangementjnfos () specify CHUNK_0011 and 
CHUNK_001 2 respectively. Thus, a chunk group can be 
used to specify an order in which a plurality of chunks 
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are to be played back. 

[0066] To put it concretely, first of all, an initial value 
of a timer for the chunk group is determined by . 
chunkgroup_time_base_offset in the CHUNKGROUP_ 
###.CGIT file shown in Fig. 21 . Then, when each chunk 
is cataloged, presentation_start_cg_time_count and 
presentattion_end_cg_time_count of chunk_arrange- 
menljnlo ( ) shown in Fig. 23 are specified. 
[0067] For example, assume that the time lengths of 
CHUNK_0011 and CHUNK_0012 are A and B respec- 
tively as shown in Fig. 28. In this case, 
presentation_start_cg_count and presentation. 
end_cg_count of CHUNK_0011 are equal to 
chunkgroup_time_base_offset and chunk_group_ 
time_base_offset+A respectively. On the other hand, 
presentation_start_cg_count and presentation. 
end_cg_count of CHUNK_0012 are equal to 
chunkgroup_time_base_offset+A and chunk_group_ 
time_base_offset+A+B respectively. By setting the 
fields in this way, CHUNKGROUP_002 is defined so that 
CHUNK_0011 and CHUNK_001 2 are played back con- 
tinuously. 

[0068] It should be noted that, if the playback time of 
CHUNK_0011 overlaps the playback time of 
CHUNK_0012, one of the playback times can be shifted 
to eliminate the overlapping. In addition, trans it ion_info 
( ) in chunk_arrangemenMnfo ( ) shown in Fig. 23 is 
used as a descriptive field used for specifying a special . 
effect such as a fade-in, a fade-out or a wipe in a tran- 
sition from one stream to another one. 
[0069] In the example shown in Fig. 26 (or Fig. 27), 
the TITLE_001 .VDR and TITLE_002.VDR title informa- 
tion files specify the CHUNKGROUP_001 CGIT chunk- 
group information file whereas the TITLE_003. VDR title 
information file specifies the CHUNKGROUP_ 
002.CGIT chunk-group information file; To put it con- 
cretely, a cgit_file_id field in titlejnfo ( ) shown in Fig. 
16 specifies the file ID of the chunk group. In addition, 
fields named title_start_chunk_group_time_stamp and 
title_end_chunk_group_time_stamp are used for spec- 
• ifying a time range in which the title is defined in the 
chunk group. 

[0070] In the example shown in Fig, 27, for example, 
TIT.LE_001 and TITLE_002 specify the first and second 
. halves of CHUNKGROUP 001. It should be noted that 
the division conforms to a request made by the user and 
its position is determined arbitrarily by the user instead 
of being determined in advance. In this example, let the 
position of division into TITLE_001 and TITLE_002 be 
set at a location separated away from the head of 
CHUNKGROUP_001 by a distance of A. 
[0071] TITLEJ301 specifies CHUNKGROUP_001 as 
a chunk group and a start time of CHUNKGROUP_001 
as a start time of the title. As an end time of the title, a 
time of a point specified by the user is specified. 
[0072] That is to say, as title_start_chunk_ 
group_time_stamp of TITLE 001, chunkgroup_time_ 
base_offset (the position of the head) of 



CHUNKGROUPJ)01 is set whereas, as title_end_ 
chunk_group_time_stamp of TITLE_001, a sum of 
chunkgroupJime_base_offset of CHUNKGROUP_001 
. and the distance A is set. 

s [0073] TITLE_002 specifies CHUNKGROUP_001 as 
a chunk group and a time of a point specified by the user 
is specified a start time of the title. As an end time of the 
title, an end time of CHUNKGROUP_001 is specified. 
[0074] That is to say, as title_start_chunk_group_ 

10 time_stamp of TITLE_002, a sum of chunk- 
group__time_base_offset (the position of the head) of 
CHUNKGROUP_001 and the distance A is set whereas, 
as title_end_chunk_group_time_stamp of TITLE_002, 
a sum of chunkgroup_time_base_offset of CHUNK- 

15 GROUP.001 and the length of CHUNKGROUP_001 is 
set. 

[0075] TITLE_003 specifies CHUNKGROUP_002 as 
a chunk group and a start time of CHUNKGROUP_002 
is specified a start time of the title. As an end time of the 

20 title, an end time of CHUNKGROUP_002 is specified. 
[0076] That is to. say, as title_start_chunk_ 
group_time_stamp of TITLE_003, chunkgroup_time_ 
base_otfset (the position of the head) of 
CHUNKGROUP_002 is set whereas, - as title_end_ 

2S chunk_group_time_stamp of TITLE_003, a sum of 
chunkgroup_time_base_offset of CHUNKGROUPJ)02 
and the length of CHUNKGROUP_002 is set. 
[0077] In addition, in this example, the program infor- 
mation file named PROGRAM_001.PGI specifies that 

30 part of TITLE_001 and part of TITLE J)03 be played 
back in an order the parts are enumerated. To put it con- 
cretely, title_number in playjtem ( ) shown in Fig. 20 is" 
used for specifying a title. Times defined by a title are 
used for defining start and. end points to extract a cut. A 

35 plurality of such cuts are gathered to compose a pro- 
gram. 

[0078] The following is a description of an append- 
record operation to additionally record new information 
onto the optical disc 1 . To put it concretely, this append- 

40 record operation is typically carried out as a video re- 
cording operation or carried out by the user by operating 
the input unit 14 to enter a command to perform video 
real-time recording to the optical-disc apparatus. In the 
latter case, a recording button is pressed if the video- 

4$ recording end time is not known. A button for a one- 
touch recording function is pressed, however, for a case 
in which the recording end time can be predicted. The 
one-touch recording function is a function for carrying 
out video recording for a fixed period of time. 

so [0079] The append-record operation is explained by 
taking timer recording as an example. In this case, the 
user of the optical-disc apparatus specifies, among oth- 
er things, a recording start time, a recording end time, 
the bit rate of a bit stream and a channel to be recorded 

55 in advance. In addition, at a point of time the video re- 
cording is reserved, the optical disc 1 is checked in ad- 
vance to find out whether or not there is left a free space 
suited for the bit rate and the length of the recording 
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time. 

[0080] If another recording operation is carried out on 
the optical disc 1 between a time a reservation is made 
and a time to execute the reserved video recording, it is 
quite within the bounds of possibility that the confirmed s 
free space tor implementing the reserved video record- 
ing at the specified bit rate can not be allocated any 
more. In such a case, the CPU 21 either reduces the bit 
rate to a value smaller than the specified fore in order 
to record information for the reserved period of time, or iQ 
records information for a period of time as long as pos- 

. sible by keeping the bit rate unchanged as it is. It is need- 
less to say that the CPU 21 then carries out the record- 
ing operation further and, as an inconvenience for the 
reserved video recording Is detected, a message in- 15 
forming the user of the inconvenience is issued. 
[0081] As the start time of the reserved video record- 
ing is approaching, the CPU 21 uses an embedded timer 
and a clock signal to automatically restore the optical- 
disc apparatus to an operating mode from a sleep mode, so 
Then, the CPU 21 issues a file-system operation instruc- 
tion included in the processing program from the begin- 
ning to allocate an area used for recording a reserved . 
program on the optical disc 1 . That is to say, first of all, 
the CPU 21 subtracts the start time from the end time 25 
of the reserved recording to find the length of the record- 
ing time and, then, calculates a product of the length of 
the recording time and the bit rate to find the size of the 
necessary area to be allocated for recording the re- 
served program. In addition to a stream file required in 30 
the reserved recording, data may need to be stored in 
an information file. To be more specific, when a new title 
needs to be stored in a title information file, an area has 
to be allocated on the optical disc 1 for recording the title 
information file. If an area with a sufficient size can not 35 
be allocated, it is necessary to adopt the counlermeas- 
ure technique described above, that is, reduction of the 
bit rate or carrying out a recording operation only for a 
period of time corresponding to the allocated area. 
[0082] It should be noted that, since a new title is <o 
stored in this case, the user gives a name to a new 

. stream file, strictly speaking, to a new stream file in a 
new stream directory. Let the name be ¥MPE- 
G AWSTRE AM_003V CHUNK_0031 . That is to say, the . 
name of the stream file is CHUNK__0031.MPEG2 in the 
STREAM_003 directory under the MPEGAV directory in 
the root directory as shown in Fig. 29. 
[0083] The CPU 21 issues instructions of execution 
in the recording mode to other components of the opti- 
cal-disc apparatus. For example; a video signal re- so 
ceived through the input terminal P3 and an audio signal 
through the input terminal P4 from a tgner not shown in 
the figure are encoded by the encoder 10 and then 
stored in a write-in channel buffer 11 . Then, the CPU 21 
moves the optical head 2 to a write position determined 55 
by information on an address of the area allocated ear- 
lier. The CPU 21 then sets the optical head 2, the RF & 
demodulation/modulation circuit 3 and the ECC circuit 
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4 in a write-in mode and positions the switch 5 on the 
side of the write-in channel buffer 11. After the position 
of the optical head 2 has been finely adjusted, a write- 
in operation using the optical head 2 is started. At that 
time, data to be recorded in a newly provided file named 
CHUNK_0031.MP.EG2 is read out from the write-in 
channel buffer 11 to be recorded onto the optical disc 1 
by way of the switch 5, the ECC circuit 4, the RF & de- 
modulation/modulation circuit 3 and the optical head 2. 
[0084] When one of the following events occurs dur- 
ing the write-in operation described above, the CPU 21 
halts the operation. 

1 The end time of the reserved video recording is 
reached. 

2 Information can no longer be recorded onto the 
optical disc 1 due to a reason such as an insufficient 
storage capacity 

3 An instruction to stop the recording operation is 
received. 

[0085] Next, by using a file-system operation instruc- 
tion included in the processing program in advance, the 
CPU 21 updates a pointer pointing to CHUNK_ 
0031 .MPEG2 in the file system with a value pointing to 
a location at which information has been newly record- 
ed. In addition, the CPU 21 prepares files respectively 
for chunk information, chunk-group information and title 
information, gives a name to each of the files and 
records the information into the files. It should be noted 
that free spaces for recording the files need to be allo- 
cated in advance on the optical disc 1 during the record- 
ing operation or at the reservation time. 
[0086] As a result, new information files are created 
typically as shown in Fig. 30. In the figure, files names 
each with an asterisk mark provided on the right side 
thereof are the names of the files newly created in the 
operation described above. 

[0087] Fig. 31 is a diagram showing a relation among 
the newly created information files. As shown in the fig- 
ure, TITLE_004 specifies CHUNKGROUP_003 specify- 
ing CHUNK_003l which specifies STREAM_0031. 
[0088] That is to. say, a new stream is recorded in an 
information file as TITLE__004. By using a function of the 
optical -disc apparatus to verify a title, the user is capa- 
ble of knowing information such as attributes of 
TITLE_004. In addition. TITLE_004 can be played back. 
[0089] The following is a description of an operation 
to overwrite/record information on an optical disc 1 like 
one shown in Fig. 26 (or Fig. 27). Much like an operation 
to record a signal onto a video tape, an overwrite -record 
operation is an operation to record a new program over 
an existing program already recorded on the opticai disc 
1 , erasing the existing program. 

[0090] In the overwrite-record operation, a position to 
start the operation is important. Assume that the user 
specifies the head of TITLE_001 as a position to start 
an overwrite-record operation. In this case, the over- 
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write-record operation is carried out by overwriting ex- 
isting information recorded in TITLEJ301, TITLE_002 
and TITLE JX)3 in an order they are enumerated. If the 
overwrite-record operation has not been finished even 
if the end of TITLE_003 is reached, the recording oper- 
ation is continued by allocating a new free area on the 
optical disc 1 . If TITLE_002 is specified as a location to 
start* an overwrite- record operation, information in 
TITLE_001 will not be overwritten by the recording op- 
eration because TITLE_Q01 precedes the start location 
of the operation. 

[0091] Assume that timer video recording is carried 
out by overwriting existing information starting with that 
at the head of TITLE_003. In this case, the user of the 
optical-disc apparatus specifies, among other things, a 
recording start time, a recording end time, the bit rate of 
a bit stream and a channel to be recorded in advance. 
In addition, the head of TITLE_003 is specified as a re- 
cording start location which is of importance to the over- 
write-record operation.- Furthermore, also in this ease, 
at a point of time the video recording is reserved, the 
existence of a space suited for the bit rate and the video 
recording time on the optical disc 1 is verified in ad- 
vance. In the case of an overwrite-record operation, a 
sum of the total size of a plu ralrty of rewritable titles start- 
ing from a specified location and free areas on the op- 
tical disc 1 is a recordable space. To be more specific, 
in this case, a sum of the total size of STREAM_0011 
and STREAM_0Q12 streams controlled by TITLE_003 
and a free area on the optical disc 1 is a recordable 
space. 

[0O92] In a overwrite-record operation, for the record- 
able space described above, there are some items 
available for selection as to what order the video record- 
ing is to be actually carried out. As a first conceivable 
item of selection, it is possible to select a technique to 
record information in an order streams are specified in 
the title. To be more specific, in this case, it is possible 
to select a technique wherein the video recording is 
started from the head of STRE AMJ301 1 and, as the end 
of STREAM_0011 is reached, the recording iscontinued 
to the head of STREAM_0012. Then, as the end of 
STREAM_0012 is reached, the video recording is con- 
tinued to the Iree space on the optical disc 1 . As another 
technique, first of all, the video recording is carried out 
on the free area on the optical disc 1 and, at a point of 
time the free area is all used up, the recording is contin- 
ued to an existing stream. 

[0093] The former technique is excellent in a sense 
that the technique emulates a video tape. That is to say, 
since the recording operation resembles an operation 
to record information onto a video tape, the operation is 
characterized in that the user is capable of comprehend- 
ing the operation with ease. On the other hand, charac- 
terized in that an already recorded stream is erased lat- 
er, the latter technique is excellent in a sense that re- 
corded information is protected. 
[0094] It should be noted that, if another recording op- 



eration is carried out on the optical disc 1 between a 
time a reservation is made and a time to execute the 
reserved video recording, it is quite within the bounds of 
possibility that the confirmed free space for implement- 

s ing the reserved video recording at the specified bit rate 
can not be allocated any more. In such a case, much 
like the append-record operation described earlier, the 
CPU 21 either automatically reduces the bit rate to a 
value smaller than the specified fore in order to record. 

10 information for the reserved period of time, or records 
information for a period of time as long as possible by 
keeping the bit rate unchanged as it is. 
[0095] As the start time of the reserved video record- 
ing is approaching, the optical-disc apparatus is re- 

*5 stored from a sleep mode to an operating mode. The 
CPU 21 allocates all free areas on the optical disc 1. It 
is needless to say that there is also a method whereby 
a free area is not allocated at this point of time but allo- 
cated at a point. of time such an area is required. For the 

20 sake of explanation simplicity, a required area is allocat- 
ed prior to the start of recording. 
[0096] It should be noted that since the size of a re- 
quired area is known in advance in timer recording due 
to the fact that a start :time, an end time and a bit rate 

25 are specified, only an area with a required size or a re - 
* quired size plus a certain additional margin can be allo- 
cated. In case it is necessary to record information files 
such as a case in which a title information file to be re- 
corded as a new title is required during recording, how- 

30 ever, an area with a size sufficient for recording the in- 
formation files needs to be allocated. 
[0097] A name is given to a new stream file, strictly 
speaking, a new stream file in a new stream directory. 
Let the name be ¥MPEGAV¥STREAM_002¥CHUNK_ 

35 0031. That is to say, the name of the stream file is 
CHUNK_0031.MPEG2 in the STREAM_002 directory 
under the MPEGAV directory in the .root directory as 
shown in Fig. 32. 

[0098] .A video signal received through the input ter- 

40 minal P3 and an audio signal through the input terminal 
P4 from a tuner not shown in the figure are encoded by 
the encoder 10 and then stored in a write-in channel 
buffer 11. Then, the CPU 21 moves the optical head 2 
to a write position determined by information on an ad- 

45 dress of the area allocated earl ier. The C PU 2 1 then sets 
the optical head 2, the RF & demodulation/modulation 
circuit 3 and the ECC circuit 4 in a write-in mode "and 
positions the switch 5 on the side of the write-in channel 
buffer 11. After the position of the optical head 2 has 

50 been finely adjusted, a write-in operation using the op- 
tical head 2 is started. At that time, data to be recorded 
in a newly provided file named CHUNK J)031 MPEG2 
is read out from the write-in channel buffer 11 to be re- 
corded onto the optical disc 1 by way of the switch 5. 

55 the ECC circuit 4, the RF & demodulation/modulation 
circuit 3 and the optical head 2. 

[0099] At that time, first of all, the stream file named 
CHUNK_0011.MPEG2 is rewritten. After the recording 
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has reached the end of the stream file named 
CHUNK_0011 .MPEG2, then, the operation is continued 
to a stream file named CHUNKJD012.MPEG2 prior to 
continuation to a. stream tile named CHUNK_ 
0031.MPEG2. 

[01 00] While the processing described above is being 
carried out, the CPU 21 halts the write-in operation at a 
point of lime any one of the 3 conditions described ear- 
lier is met. 

[0101] Then, Ihe CPU 21 executes a file-system op- 
eration instruction included in the processing program 
in advance to update the stream files, chunk informa- 
tion, chunk-group information and title information. 
[0102] By the way, the configuration of files is 
changed with timing synchronized to completion of the 
write-in operation. For example, when recording is car- 
ried out on the stream file named CHUNK_ 
0031.MPEG2 after the write-in operations of the 2 
stream files named CHUNK_0011 .MPEG2 and 
CHUNK_0012.MPEG2 have been completed, the con- 
figuration of files on the optical disc 1 is changed to one 
shown in Fig. 33. A file name with an asterisk mark 
appended on the right side thereof is the name of a file 
newly created this time. 

[0103] Fig. 34 is a diagram showing a relation of files 
newly created in this way, that is, files shown in Fig. 33. 
When compared with that shown in Fig. 31 , it is obvious 
that CHUNK_0031 is added as a chunk included in 
CHUNKGROUP_002 specified by TITLE_003 and 
CHUNK_0031 specifies STREAM_0031. 
[0104] On the other hand, if the overwrite-record op- 
eration is completed while data is being written into an 
existing stream file, that is, if the overwrite-record oper- 
ation is completed while data is being written into, the 
stream file named CHUNK_0011 .MPEG2 for example, 
the free area allocated for the overwrite operation on the 
stream file- named CHUNK_0031.MPEG2 is released 
because no data is overwritten into the file. In this case, 
special title processing is carried out. To put it in detail, 
when an overwrite-record operation is started at the 
head of TITLE_003 and the operation is completed in 
the middle of it, the title is split. To be more specific, as 
shown in Fig. 35. new TITLE_003 is assigned to a region 
between the start position of the overwrite-record oper- 
ation and the position of completion whereas 
TITLE_004 is given to an area following the region, that 
is, the rest of the area to which TITLE_003 is supposed 
to be assigned originally. 

[0105] Next, an operation to play back a title is ex- 
plained. Now, assume that an optical disc 1 havingiiles 
shown in Fig. 26 is inserted into the optical-disc appa- 
ratus and a title is then played back from the disc 1. 
When the optical disc 1 is inserted into the~apparatus, 
first of all, the CPU 21 reads out data from information 
files on the optical disc 1 and stores the data into the 
RAM unit 24, This processing is carried out by repeating 
the basic operation to read in data from an information 
file described earlier. 



[0106] To be more specific, first of all, the CPU 21 
reads out data from VOLUME.TDC and ALBUM. STR. 
Then, the CPU 21 examines the directory named TITLE 
to find out how many files with a name extension VDR* 

5 exist in the directory. A file with such a name extension 
is a file having title information. The number of files is 
equal to the number of titles. In the example shown in 
Fig. 26, the number of titles is three. Then,, the CPU 21 
reads out title information from the three files and stores 

io the information into the RAM unit 24. 

[0107] The CPU 21 controls the OSD control circuit 9 
to let the OSD control circuit 9 generate character infor- 
mation, that is, information on titles recorded on the op- 
tical disc 1 . The character information is synthesized by 

75 the synthesis circuit 8 with a video signal. A result of the 
synthesis is then output through the output terminal P1 
to be displayed on the display unit. To be more specific, 
the length and attributes of each of the 3 existing titles 
existing in this example are displayed. The attributes in- 

20 elude the name of the title and a date on which the title 
was recorded. 

[0108] Assume that the user specifies TITLE_002 as 
a title to be played back for example. In the information 
file of TITLE_002, lo be more specific, in thecgit_file_id 
2S field of titlejnfo ( ) shown in Fig. 16, a file ID specifying 
CHUNKGROUP_001 is recorded. The CPU 21 records 
the file ID and stores CHUNKGROUPJ301 in the RAM 
unit 24. . 

[0109] Then, the CPU 21 examines which CHUNK the 

30 start and end times of TITLE_002 correspond to. The 
start and end times are recorded respectively in the 
title^start_chunk_group_time_stamp and title_end_ 
chunk_group_time_stamp fields of titlejnfo ( ) shown in 
Fig. 16. The examination is carried out by comparison 

35 with information included in information on a CHUNK- 
GROUP in which their respective chunks have been re- 
corded. To be more specific, the examination is done by 
comparison with information recorded in the 
presentation_start_cg_time_count and presentation^ 

40 end_cg_time__count fields of chunk._arrangement.jnfo 
( ) shown in Fig. 23. In this example, the start time of 
TITLE.002 is known to be in the midst of CHUNK_0001 
as shown in Fig. 27. That is to say, it is obvious that, in 
order to play back TITLE _002 from the head thereof, the 

45 playback operation needs to be started from the middle 
of the CHUNK_0001.MPEG2 stream file. 
[0110] Subsequently, the CPU 21 examines the 
stream in order to determine which part- of the stream 
corresponds to the head of TITLE_002. That is to say. 

so the CPU 21 computes the magnitude of an offset time 
(a time stamp) in the stream corresponding to the head 
of TITLE J)02. Next, by using characteristic-point infor- 
mation in the CHUNK file, a playback start point corre- 
sponding, to a point immediately before the start time is 

55 identified. In this way, an offset distance of the playback 
start point from the head of the file can be confirmed. 
[0111] Then, by using a file-system operation instruc- 
tion included in the processing program in advance, the 
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CPU 21 confirms a physical address on the optical disc 
1 in which CHUNK_OO01.MPEG2 has been recorded 
and the length thereof. Further, the offset address of the 
playback start point touhd earlieris added to this phys- 
ical address to finally confirm the address of the play- 
back start point of TITLE_002. 

[0112] Subsequently, the CPU 21 moves the optical 
head 2 to a read-out position delermined by information 
• on the address of the CHUNK_0001.MPEG2 file. The 
CPU 21 then sets the optical head 2, the RF & demod-. 
ulation/modulation circuit 3 and the ECC circuit 4 in a 
read-out mode and positions the switch 5 on the side of 
the read-out channel buffer 6. After the position of. the 
optical head 2 has been finely adjusted, a read-out op- 
eration using the optical head 2 is started. At that time, 
data read out from the file named CHUNK_ 
0001 MPEG2 is stored in the read-out channel buffer 6. 
[0113] The data stored in the read-out channel buffer 

6 is then output to the decoder 7 to be decoded thereby. 
As results of decoding, the decoder 7 outputs video and 
audio signals. At a point of time the amount of the data 
read out from the optical disc 1 , decoded by the decoder 

7 and displayed on the display unit becomes equal to 
the size of the CHUNK_0001.MPEG2 file, the CPU 21 
makes the playback operation transit to TITLE_003. An 
operation to play back information from TITLE_003 is 
carried out in the same way as TITLE_002. 

[01 14] As the operation to play back data from the re- 
corded titles is completed or as an instruction to halt the 
read-out operation is received, the read-out and decod- 
ing processing is terminated. 

[0115] It should be noted that, when a new disc or a 
disc with a different format is inserted into the optical- 
disc apparatus as the optical disc 1 , the CPU 21 makes 
an attempt to read out VOLUME. TOC and ALBUM. STR 
. from the inserted disc. However, these files usually do 
not exist in the newly inserted disc. In such a case, that 
is, in case VOLUME. TOC and ALBUM. STR can not be 
read out, the CPU 21 issues a message to make a re- 
quest for an instruction from the user. In response to the 
message, the user gives an instruction to the CPU 21 
to eject the optical disc 1 in case the newly inserted disc 
has a different format, or to initialize the optical disc 1 in 
case the newly inserted disc is a new disc even with the 
same format. As an alternative, the instruction may 
cause data on the newly inserted disc to be recovered 
by using some methods in case the data has been de- 
stroyed from the disc which has the same format. 
[0116] . Next, a title is further explained. TITLE_###. 
VDR shown in Fig. 15 is a file for storing information of 
a title. Information on a title is recorded in 1 titlejnfo ( ) 
field. The number of titlejnfo ( ) fields existing in 
TITLE_###.VDR is t. Thus, as many TITLE_###.VDR 
files as titles exist in a volume. 

[0117] A title number is not defined in title_info ( ) 
shown in Fig. 16. Instead, the title number is determined 
by the name of the file or the file id. That is to say, no- 
tation ### in the file name TITLE_###.VDR is a positive 
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integer used as the title number. A title is not an infor- 
mation structure. Rather, a title is associated with a 
range in a chunk group. The range starts from a title in- 
dex representing a start point and ends at another title 
5 index representing the head of the next title, or the range 
may be part of a range ending at the end point of the 
chunk group. 

[0118] As shown in Fig. 36, filejype Jd of TIThE_###. 
VDR shown in Fig. 15 is an area used for recording a 

io string of 1 6 characters which are used as an identifica- 
tion indicating that the file is a file that includes titlejnfo 
( ) text_block () is an area used for storing a variety of 
texts. Only text items allowing the uso of text_block ( ) 
are recorded thereon. 

15 [0119] As shown in Fig. 16, titlejnfo () is an area 
used for recording the start and end points of the title on 
the chunk group and other attributes of the title. In ad- 
dition, titlejnfo ( ) can include a flag indicating whether 
or not a seamless playback operation between titles can 

20 be assured in an operation to play back the titles in the 
order of title numbers. This flag allows the optical disc 
apparatus to obtain information on whether or not a 
seamless playback operation between titles can be car- 
ried out in advance and whether or not it is necessary 

25 to change the layout when merging titles. 

[0120] A seamless playback operation within a title or 
a . chunk group is assured. Since a boundary between 
titles is also a boundary between files, however, a seam- 
less playback operation between titles can not be as- 

30 sured in some cases. It should be noted that the optical - 
disc apparatus has a function for changing the layout 
into a state allowing a seamless playback operation to 
be carried out in general. 

[0121] titlejnfojength of titlejnfo () shown in Fig. 

35 16 is an area used for recording the length of titlejnfo 
( ) expressed in terms of bytes. flags Jorjitle is a field 
for recording information on the corresponding title such 
as a write attribute (that is, whether or not an operation 
to change the title is permitted), a limit on the number of 

<o times the title can be played back and a rating level, 
cgit Jtlejd is an area used for recording the identifica- 
tion of a CHUNKGROUP_###.CGIT) information file 
■ serving as a base of the title. 

[0122] title_start_chunk_groupJime_stamp is an ar- 

45 ea used for recording a time of a playback start time of 
the title on a local time axis defined in the chunk group. 
title_start_chunk_group_time_stamp is a time to display 
pictures pointed to by the title index of the title. On. the 

* 

other hand, title_end_chunk_groupJime_stamp is an 
50 area used for recording a time of a playback end time 
of the title on a local time axis defined in the chun k group. 
title_start_chunk_groupJime_stamp is a playback end 
time of the chunk group or the value of a title index rep- 
resenting the start point of another title placed immedi- 
55 ately after the title on the time axis. 

[0123] title_playbackjime ( ) is an area used for re- 
cording the playback time of the title, that is, a time-code 
value or the number of frames or fields. 
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number_of_marks is an area used lor recording the total 
number ol all marks set in the title excluding title index- 
es. As shown in Fig. 37, mark_type is an area used tor 
recording the type of a mark placed at any position in 
the title. A mark is utilized as a random access point in 
the title. mark_chunk_group_time_stamp is an area 
used for recording a time stamp on the time axis of the 
chunk group. The time stamp corresponds to a location 
at which the mark is set in the title. Time stamps are 
arranged into an order starting with the one with a small- 
est value. Indexes with time stamps representing the 
same start and end points of a title may exist, 
stuff in g_bytes is an area used for recording stuffing 
bytes. Its length is- 8 x n bits where n ^ 0. 
[0124] Next, a chunk group and a chunk are explained 
by referring to Figs. 21 to 24. CHUNKGROUPJ*##. 
CGIT is the name of a file for storing a definition of the 
time axis of a title, the configuration of chunks and 
processing of discontinuity points included in titles. 
[0125] A title comprises a variety of bit streams such 
as streams including no video data and DV (digital vid- 
eo) bit streams. In a DV format, a time axis is prescribed 
in terms of frame units. If the STC (System Time Clock) 
of the MPEG2 video is used as a reference, the format 
varies, making it impossible to control a DV bit stream. 
[0126] For this reason, a local time axis in a title is set. 
The time axis is not dependent on streams composing 
the title. A boundary between titles is set independently 
of a boundary between chunks. Thus, rather than setting 
a local time axis for each chunk (that is, by associating 
with a bit stream on a 1-on-1 basis) or setting a local 
time axis for each title, it is proper to set a local time axis 
for a set of chunks which includes a plurality of titles, 
that is, an arbitrary number of titles. A set of chunks is 
referred to as a chunk group. 

[0127] In a chunk group, a single time axis is defined. 
On the time axis, chunks are stuck to determine times 
to display the chunks. That is to say, a chunk group is 
an arrangement of chunks in a state where the contents 
of a bit-stream file (a series of bytes) are expanded 
along the time axis. An arrangement of all chunks in- 
cluded in a bit-stream file along the time axis is referred 
to as a path. In a chunk group, a plurality of paths can 
be arranged. Paths that prescribe a playback start time- 
and a playback end time of a chunk group are referred 
to as main paths. Other paths are known as sub paths. 
A sub path mainly represents information such as an 
audio chunk which is recorded later as additional infor- 
mation. ~T 
[0128] A point of . connection between chunks does 
not necessarily coincide with a boundary between titles. 
Thus, a point of connection between chunks is not an 
attribute of a title. If a relation between chunks is includ- 
ed as an attribute of a chunk, however, there will be a 
contradiction at hierarchical layers. Information on such 
a point of discontinuity is positioned between a chunk 
and a title and it is thus considered to be appropriate to 
position at the chunk group hierarchical level. 



[0129] Jo present what* is described above in a sum- 
mary, information of a chunk group includes how to lay 
out chunks along a time axis, an order to play back the 
chunks, a point of discontinuity at a point of connection 

5 between the end of a first chunk and the beginning of a 
next chunk to be played back after the first chunk. 
[0130] It should be noted that a chunk group can also 
be used to specify streams to be played back at the 
same time. For instance, in an example shown in Fig. 

10 38, TITLE_001 specifies CHUNKGROUP_001 which 
specifies CHUNK_0001 and CHUNK.0002. At least 
portions of STREAM_0001 and STREAM_0002 speci- 
fied by CHUNK_0001 and CHUNK_0002 respectively 
overlap each other on the. time axis and will thus be 

'5 played back at the same time. 

[0131] Fig. 39 is a diagram showing a case in which 
such a chunk group is generated. In this case, chunk A 
controlling- bit stream A is synthesized together with 
chunk B controlling bit stream B. In the resulting chunk 

20 group, chunks A and.B are controlled as a main path 
and a sub path respectively. At least portions of bit 
streams A and B overlap each other and will thus be 
played back at the same time. - . 
[0132] As shown in Fig. 40, filejype_id of 

25 CHUNKGROUP_ ###.CGIT shown in Fig. 21 is an area 
represented by a string of 16 characters which conform 
, to ISO 646 and is used as an identification indicating 
that the file is a CHUNKGROUP_CGIT file, 
chun kgroup_time_base_f lags is an area used for re- 

30 cording flags regarding a reference counter of the chunk 
- group. chunkgroup_Jime_base_offset is a 64-bit area 
used for recording a start time of a reference time axis 
in the chunk group. The start time is set in a counter 
which counts up the number of 90 T kHz clock pulses. 

35 text_block ( ) is an area used for storing a variety of 
lexis. Only text ilems albwing Ihe use of texl_block ( ) 
are recorded thereon. 

[0133] As shown in Fig. 22, chunk_connection Jnfo ( ) 
is a file used for recording information: on singular points 

40 such as video change-over points and audio-video syn- 
chronization points. chunk_connection_info ( ) pre- 
scribes status of connection between chunks. At a sin- 
gular point such as a joint between 2 chunks obtained 
as a result of editing, it is necessary to transfer from one 

4S of the chunks to the other chunk in the middle of a GOP. 
Information on the vicinity of such an edit point is pre- 
scribed in chunk_connection_info (;). A chunk never 
pertains lo 2 or more chunk groups. 
[0134] chunk_connection_infojength is an area 

so used for recording the .length of chunk_connection_infb 
(.) expressed in terms of bytes. number_of_chunks is 
an area used for recording.the total number of chunks 
used in the chunk group. As shown in Fig. 41, 
chunk_sync_p1ay_flag is a flag indicating: whether or not 

ss it is necessary to play back 2 or more chunks at the same 
time. A value of 0 set in this flag indicates that only 1 
chunk is to be played back. On the other hand, a value 
of 1 indicates that a plurality of chunks are to be played 
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back at the same time. 

[0135] chunk_arrangement_info_length of chunk_ 
arrangement_info ( ) shown in Fig. 23 is an area used 
lor recording the information of the length expressed in 
terms of bytes. To put it in detail, the length is the number 
of bytes counted starting with the first byte of 
chunk_arangement_info_length and ending with the 
las I byte of trans ition_in To .( ). chunk_info_file_id is an 
area used for recording a file identification indicating 
that the file is a chunk information file. 
[0136] chunk_switch_stream_id is an area used for 
recording stream identification of a stream .to be played 
back continuously in the case of 2 chunks connected to 
each other. Typically, an identification recorded in an 
MPEG2 packet header to identify video or audio data is 
used as this stream identification. 
presentation_start_cg_time_count is an area used for 
recording a time-count value representing a display start 
time of a chunk as a time within the chunk group. The 
display start time of a chunk is expressed by a global 
time stamp defined in the chunk group. The operation 
to display the chunk is started at the display start time 
within the chunk group. On the other hand, 
presentation_end_cg_time_count is an area used for 
recording a time-count value representing a display end 
time of a chunk as a time within the chunk group. The 
display end time of a chunk is expressed by a global 
time stamp defined in the chunk group. 
[0137] As shown in Fig. 42, original_time_count_type 
is an area used for recording a type of a time count used 
in a stream. In the case of an MPEG2 video stream, for 
example, original_time_count_type has a value of 
'0000'. 

number_of_start_originaLtime_count_extension is an 
area which is used for recording the number of time 
counts each representing a newly required start lime in 
case a plurality of time counts are required. On the other 
hand, number_lof_end_original_time_count_extension 
is an area which is used for recording the number of time 
counts each representing a newty required end time in 
case a plurality of time counts are required. 
presentatton_start_original_time_count is an area used 
for recording a time within a stream or a counter value 
corresponding to presentation_start_cg_time_count. 
On the other hand, presentation_end_ original,, 
time_count is an area used for recording a time within 
a stream or a counter value corresponding to 
presentatbn_end_cg_time_count. 
[01 38] tc_ext_attributes is an area used for recording 
attributes for time_count_extension. time_counL_ex- 
tension may include, among other data, information in- 
dicating which stream time_count_extension is applied 
to. 

start_origina!_time_cqunl_extension is an area used for 
recording a start counter value or a start time necessary 
for switching from a chunk to another. This information 
is optional and used when it is necessary to record a 
" plurality of times or counter values. On the other hand, 



end_original_time_count_extension is an area used for 
recording an end counter value or an end time neces- 
sary for switching from a chunk to another. This infor- 
mation is optional and used when it is necessary to 

5 record a plurality of times or counter values. 
transition_info ( ) is an area used for recording informa- 
tion required for applying a special effect when switching 
from a chunk lo another. The information may specify a 
chunk, a switching time and the type of the special effect 

to to mention a few. 

[0139] CHUNK_%%%%.ABST shown in Fig. 24 is the 
name of a file used for recording characteristic points 
extracted from a bit stream composing a chunk identi- 
fied by a sub_file number represented by notation 

is %%%%. The file includes information such as a start 
byte position, a length and attributes for each of units 
composing a bit stream such as a GOP and an audio 
frame. GOP information and audio frame information 
are collected as a CHUNK _%%%%.ABST file for each 

20 chunk- (sub-file). 

[0140] As shown in Fig. 43, file_type_id of CHUNK „ 
%%%%. ABST is an area used for recording an identifier 
indicating that the file includes streamjnfo ( ). 
file_type_id is a string of 1 6 characters conforming to 

25 ISO 646. 

[0141] As shown in Fig. 44, info_type shown in Fig. 
24 is an area used for recording the type of stream_info 
( ) that follows. info_type identifies the type of the 
stream. number_of__programs is an area used for re- 

30 cording the number of programs included in the MPEG2 
TS (Transport Stream). In order to obtain the number of 
such programs, it is necessary to fetch a.PSI (Program 
Specific Information). In the case of an MPEG stream 
other than a TS, the number of programs is 1. 

35 number_of_streams is an area for recording the number 
of streams used in this program. The number of streams 
is equal to the number of different PIDs (packet identi- 
fications) in the case of a TS. In the case of an MPEG 
stream other than a TS, the number of streams is equal 

40 to the number of streams having stream identifications 
different from each other. 

[0142] stream_identifier is an area used for recording 
the identification of a stream or an extended identifica- 
tion of a stream. In the case of a TS, a PID is utilized. 

45 [0143] slot_unit_type is an area used for recording 
how to delimit a stream in the case of a stream delimited 
at fixed intervals as shown in Fig. 45. In the case of a 
time delimiter index such as a delimiter for a frame and 
* a field, a time stamp value is used. slot_time_length is 

50 an area used for recording a time corresponding to a 
slot. slot_time_length is the value of a time stamp using 
a counter for counting the number of 90-kHz clock puls- 
es. number_df_slots is an area used for recording the 
number of slotjnfo (.) fields included in CHUNK_ 

55 %%%%.ABST. 

number_of J_pictures_in_a_slot is an area used for re- 
■ cording the number of l-pictures included in a slot. 
number_ofJ_pictures_in_a_slot is an integer in the 
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range 1 to 15. It should be noted, however, that the 
number of l-pictures included in a slot immediately pre- 
ceding a slot having a GOP header as a head thereof 
may be smaller than number_oM.j5ictures_Jn JL a_sfot. 
When setting a slot having the picture header of an I 
picture as a head thereof not succeeding immediately a 
' GOP header, 
number_oM_pictures_in_a_slol is used. 
[0144] Next, information on a. program shown in Figs. 
17 and 18 is further explained. Only one program ( ) field 
exists in PROGRAM_$$$.PGI. As many PROGRAM. 
$$$.PGI files as programs exist in a volume. The 
number of a program is not defined in program ( ). In- 
stead, the number of a program is determined by the 
name of the file or the file id. 

[0145] As shown in Fig.46, file_type_id of 
PROGRAM_$$$.PGI shown in Fig. 17 is an area used 
for recording a string of 16 characters used as an iden- 
tification indicating that the file is a file that includes pro- 
gram ( ) thereon. 

text_block ( ) is formed for storing a variety of texts. Only 
text items allowing the use of text_block ( ) are recorded 
thereon. 

[0146] flags_for_program of program ( ) shown in Fig. 
* 18 is an area used for recording a variety of flags for the 
program such as a write attribute (whether or not an op- 
eration to change the program is permitted),, a limit on 
the number of times the program can be played back 
and a rating level. 

[0147] As shown in Fig. 47, program_status is an area 
used for recording attributes of the program. This field 
is set optionally. If it is desired to set nothing in this field, 
however, "none" must be described therein. 
[0148] program_playback_time ( ) is an area used for 
recording the playback time of the program. 
number_of_play_sequences is an area used for record- 
ing the number of play_sequences used in the program. 
In this example of the format, however, the number of 
play sequences is set at a fixed value of 1 . That is to 
say, since at 1 program = 1 channel play back operation 
is set in this example of the format, in order to implement 
an operation to play back 2 channels at the same time, 
the simultaneous playback specification of 2 programs 
. needs to be enabled. If there is no restriction as to 1 
program = 1 channel playback operation, with 1 pro- 
gram, a 2-channel simultaneous playback operation is 
possible. In an operation to play back 2 play sequences 
at the same time by using a multichannel I/O, the optical- 
disc apparatus determines an output channel to which 
each play sequence is assigned. 
[0149] number_pf_play_lists is an area used for re- 
cording the number of play lists used in this play se- 
quence. In this example, the number of play lists is set 
at 1. 

play_list_start_time_stamp_offset is an area used for 
recording a time in a play sequence obtained as a result 
of counting by means of a timer starting from the start 
time of the play sequence. This value is a start time of 



the play list. In a program, only 1 play list is allowed to 
exist in a play sequence. The time-unit system is based 
on a frequency of 90 kHz. That is to say, the smallest 
time unit is 1/90,000 seconds. stuffing_bytes is an area 
5 used for recording stuffing bytes. Its length is 8x n bit 
where n^O. 

[0150] Next, title edit processing to .split and move a 
title is explained. In a title splitting operation, an existing 
title is split at a position specified by the user to create 

10 new titles. In a title moving operation; the order of titles 
is changed. The format structure of a title information 
file described above is a structure that allows a title split- 
ting operation and a title moving operation to be carried 
out with ease. That is to say, according to the formats 

'5 described above, a chunk group, that is, a structure 
body comprising a collection of bit-stream files, and a 
title, that is, a structure body recognized by the user as 
- a title are broken down into pieces of information in such 
a way that, in operations to split or move a title, it is not 

20 necessary to change information under a chunk group. 
[0151] Next, processing to split a title is explained by 
referring to a flowchart shown in Fig; 48. As shown in 
the figure, the processing starts with a step S1 , at which 
the user specifies a split point. For example, a predeter- 

25 mined location in TITLE_002 shown in Fig. 27 is speci- 
fied as a split point. The flow of the processing then goes 
on to a step S2 at which the CPU 21 creates an infor- 
mation file named.TITLE_002.VDR for a first title having 
the start point of the title to be split, that is, TITLE_002 

30 before splitting, as its start point and the split point as 
its end point. 

[01 52] Then, the flow of processing proceeds to a step 
S3 at which the CPU 21 creates an information file 
named TITLE_003 VDR for a second title having the 

35 split point as its start point and the end point of the title 
to be split, that is, TITLE_002 before splitting, as its end 
point. N 
[0153] Subsequently, the flow of the processing con- 
tinues to a step S4 at which the CPU 21 changes the 

40 name of a title following the split title. To be more spe- 
cific, TITLE_003 shown in Fig. 27 is changed to 
T!TLE_004 to result in titles shown in Fig. 49. 
[0154] As described above, information on a chunk 
group, chunks and streams is not.changed at all even if 

45 a title is split. 

[0155] Next, processing to swap titles is explained by 
referring to a flowchart shown in Fig. 50. To be more 
specific. TITLE_002 shown in Fig. 49 is swapped with 
TITLE_003 shown in the same figure. 

so [0156] As shown in Fig. 50, the processing begins 
with a step S11 at which the CPU 21 changes the name 
TITLE_002 of the title having a number of 002 to 
TITLE_X for a title with a number X. Thellow of the 
processing then goes on to a step S1 2 at which the CPU 

55 21 changes the name TITLE_003 of the title having a 
number of 003 to TITLE_002 for the title with the number 
002. Then, the flow of the processing proceeds to a step 
S13 at which the CPU 21 changes the name TITLE X 
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of the title having the number X to TITLE_003 for the 
title with the number 003. 

[0157] As described above, the CPU 21 changes the 
. name TITLE_002 of the title having the number 002 to 
TITLE_X for a title with the number X first before chang- 5 
ing the name TITLE_X of the title having the number X 
to TITLE_003 for the title with the number 003. It is be- 
cause of avoiding such lhai. if ihe CPU 21 changes ihe 
name TITLE_002 of the title having the number 002 to 
TITLE_003 for the title with the number 003 right away, io 
there will be 2 titles having the same number 003 before 
the CPU 21 changes the name TITLE_003 of one of the 
2 titles having the number 003 to TITLE_002 for the title 
with the number 002. 

[0158] In the processing shown in Fig. 50, is 
TITLE_002, the title with the number 002, is swapped 
with TITLE_003. a title with the number 003, as. shown 
in Fig. 51 . 

[0159] Fig. 52 shows a flowchart representing 
processing to delete a title. As shown in the figure, the 20 
processing begins with a step S21 at which the user ' 
specifies a title to be deleted. The flow of the processing 
then goes on to a step S22 at which the CPU 21 forms 
a judgment as to whether or not a chunk group, chunks 
and streams associated with the specified title are also 25 
associated with another title. If they are not associated 
with another title, the flow of the processing proceeds to 
a step.S23 at which the CPU 21 deletes the chunk 
group, the chunks and the streams associated with the 
specified title. .30 
[0160] If the outcome of the judgment formed at the 
step S22 indicates that the chunk group, the chunks and 
the streams associated with the specified title are also 
associated with another title, on the other hand, deletion 
of the chunk group, the chunks and the streams will 3s 
cause them to cease Irom existing. Thus, in this case, 
the operation carried out at the step S23 is skipped. 
[0161] After completing the operation carried out at 
the step 23 or if the outcome of the judgment formed at 
the step S2? indicates that the chunk group, the chunks *o 
and the streams associated with the specified title are 
also associated with another title, the flow of the 
processing continues to a step S24 at which the CPU 
21 processes remaining information files, that is, infor- 
mation files that were not deleted. To put it in detail. <s 
since a title was deleted, the numbers assigned to titles 
following the deleted one are each incremented by 1 . It 
should be noted, however, that if the outcome of the 
judgment formed at Ihe step S22 indicates that the 
chunk group, the chunks and the streams associated so 
with the specified title are also associated with another 
title, the specified title is in essence not deleted. In this 
case, the OSD control circuit 9 outputs a message stat- 
ing that the specified title is in essence not deleted to ' 
the display unit. ss 
[0162] After TITLE_002 has been deleted as de- 
scribed above, the former TITLE_003 file is changed to 
TITLE JX>2 and the former TITLE_004 file is changed 
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to TITLE_003 as shown in Fig. 53. At the same time, the 
former CHUNKGROUP_001 chunk group is split into 
CHUNKGROUP_001 and CHUNKGROUPJX)2 and 
the former CHUNKGROUP_002 chunk group is 
changed to CHUNKGROUP_003. In addition, the 
former STREAM_001 bit stream is split into 
STREAM_001 and STREAM_002. 
[0163] The above description shows thai, in a typical 
operation to delete a title, a stream is deleted to increase 
the size of a free area. On the other hand, there is also 
a technique to delete a title by erasing only information 
on the title which is used as control information. In this 
case, a stream occupying a physical area is not actually 
deleted so that the chunk group, chunks and streams 
associated with the title are not changed at all even if 
the title is deleted. 

[0164] Next, processing to merge titles is explained 
by referring to a flowchart shown in Fig. 54. As shown 
in the figure, the processing begins with a step S31 at 
which the user specifies titles, to be merged. For exam- 
ple, titles to be merged are TITLE_002 and TITLE_003 
shown in Fig. 49. The flow of the processing then goes 
on to a step S32 at which the CPU 21 creates a title 
having the start point of the head title, that is, 
TITLE_002, as a start point thereof and the end point of 
the tail title, that is, TITLE_003, as an end point thereof. 
In this example, the created file is named TITLE J002. 
[01 65] Then, the flow of the processing proceeds to a 
step S33 to carry out deletion processing of titles prior 
to the merging. In this case, the former TITLE_002 title 
and TITLE_003 are deleted. Subsequently, the flow of 
the processing continues to a step S34 at which the CPU 
21 processes information files of titles following the 
merged titles. To be more specific, in this case, 
TITLE_004 shown in Fig. 49 is changed to T1TLE_003. 
As a result, titles shown in Fig. 27 are obtained. 
[0166] It should be noted that, in the example given 
above, 2 titles pertain to a same chunk group and are 
adjacent to each other. In another case, 2 titles to be 
merged have their own chunk groups, chunks and 
streams. In processing to merge such 2 titles, the chunk 
groups, the chunks and the streams are rearranged in 
an order by which the titles are merged to form a single 
chunk group. 

[0167] Next, a program is explained. An operation to 
play back a program means an operation to collect'nec- 
essary portions of titles and to play back the collected 
portions without carrying out irreversible editing of the 
raw material, that is, the stream. A structure for imple- 
menting this operation is referred to as a program. An 
operation to play back a program is also referred to as 
a pointer playback operation. 

[0168] A program comprises of a plurality of play se- 
quences which each comprises a plurality of play lists. 
A play sequence controls an output channel. Which out- 
■ put^hannel of the optical-disc apparatus is assigned to 
a play sequence is determined in accordance with spec- 
ifications of the optical-disc apparatus. 
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[0169] A play list of a play sequence is used for ex- 
pressing overlaps of decoding and display operations 
among play items along the time axis. To put it in detail, 
play items are arranged in a play list in such a way that 
pieces of processing of the play items do not overlap on 
the time axis. Thus.play items in a play list can be proc- 
essed sequentially. 

[0170] in this formal example, however, a program 
has only 1 play sequence which has only 1 play list. 
[0171] A play list comprises play items which are ar- 
ranged so that there are no overlaps in display times. In 
a program, a play item is represented by a pair. of an in- 
point and an out-point which point to an area in a title. 
At a joint between play items, a playback operation may 
be seamless or may not so sometimes. That is to say, 
a seamless playback operation is not assured. 
[0172] Processing to set an operation to play back a 
program is explained by referring to a flowchart shown 
in Fig. 55. Now, assuming for example that in a state 
where PROGRAM_001 exists as shown in Fig. 27, an- 
other program PROGRAMJD02 is created. 
[0173] As shown in Fig. 55, the processing begins 
with a step S41 at which the user specifies a title and in 
and out -points in the title to play back. For example, pre- 
determined first and second locations in TITLE_003 are 
specified as in and out-points respectively as shown in 
Fig. 56. 

[01,74] The flow of the processing then goes on to a 
step S42 at which the CPU 21 sets the title specified at 
the step S41, that is. TITLE_003, in title_number of 
play_item ( ) of playjist of program ( ), the in-point spec- 
ified at the step S41 in item_start_time_stamp and the 
out-point specified at the step S41 in 
item_end_time_stamp. It should be noted that 
playjtem ( ), playjist and program ( ) are shown in 
Figs. 20, 19 and 18. respectively 

[01 75] Then, the flow of the processing proceeds to a 
step S43 at whichthe CPU 21 creates PROGRAM_$$$. 
PGI as a file for storing program ( ) and records the file 
into, the optical disc 1 . It should be noted that notation 
$$$ in the name of the file is the number of the created 
program. Thus, notation $$$ is 002 in this case. As de- 
scribed above, PROGRAM_002 shown in Fig. 56 is cre- 
ated. 

[01 76] Next, processing to play back a program is ex- 
plained by referring to a flowchart shown in Fig. 57. As 
shown in the figure, the processing begins with a step 
S51 at which the CPU 21 reads out information files from 
an optical disc T which includes information like ones 
shown in Fig. 27 or 56 by repeating the basic operation 
to read in an information file described earlier as soon 
as the user mounts the optical disc 1 on the optical-disc ' 
apparatus. The CPU 2firstores the information files into 
the/RAM unit 24. 

[0177] To put it in detail, first of all. the CPU 21 reads 
out VOLUME.TOC and ALBUM. STR and then makes 
an inquiry to. the file system about the number of files 
each with an extension of ".PGI" placed under a direc- 



tory named "program". A file with the extension ".PGI" 
is a file for storing information on a program playback 
file. The number of files each with the extension ".PGI" 
is the number of programs that can be played back. In 

5 the example shown in Fig. 27, the number of files each 
with an extension of ".PGI" is 1. In an example shown 
in Fig. 56, on the other hand, the number of files each 
wilh an extension ol ".PGI" is 2. 
. [0178] The flow of the processing then goes on to a 

10 step S52 at which the CPU 21 controls the OSD control 
circuit 9 to read out information such as the number of 
programs that can be played back, their lengths and 
their attributes from the RAM unit 24 and output them to 
the display unit. The attributes include the name of each 

'5 program and the time and the date at which each pro- 
gram was recorded. 

[0179] Then, the flow of the processing proceeds to a 
step S53 at which the user specifies a program to be 
played back. Since there are 2 programs that can be 

20 played back in the example shown in Fig. 56, the user 
specifies one of them by operating the input unit 14. As 
the user specifies a program to be played back, the flow 
of the processing continues to a step S54 at which the 
CPU 21 carries out an operation to play back the spee- 
ds ified program. 

[01 80] In the operation to play back the specified pro- 
gram carried out at the step S54, theprogram is played 
back from a position indicated by the specified in-point 
to a position indicated by the specified out-point. For ex- 

30 ample, in the case of an operation to play back 
PROGRAM_00.1 of the example shown in Fig. 56, a 
range from an in-point to an out-point in TITLE_001 and 
a range from an in-point to an out-point in TlTLE_003. 
are played back. In the case of an operation to play back 

35 PROGRAM_002, on the other hand, a range from an in- 
point to an out-point in TITLE_003 is played back. 
[0181] Then, the flow of the processing goes on to a 
step S55 at which the CPU 21 forms a judgment as to 
whether or not the operation to play back a program has 

*o been completed. If the operation has .not been complete 
ed yet, the flow of the processing goes back to the step 
S54 to repeat the execution of the processing at that 
step and the subsequent processing. If the outcome of 
the judgment formed at the step S55 indicates that the 

45 operation to play back a program has been completed, 
on the other hand, the flow of the processing proceeds 
to a step S56 at which the CPU 21 forms a judgment as 
to whether or not there is another program to be played 
back. If there is another program to be played back, the 

50 flow of the processing goes back to the step S53 to re- 
peat the execution of the processing at that step and the 
subsequent processing. If the outcome of the judgment 
formed at the step S56 indicates that all programs have 
been played back, on the other hand> the processing is 

55 terminated. 

[0182] Relations among a program, a play sequence 

and play items are shown in Figs. 58 to 60. 

[0183] As shown in Fig. 58, a program comprises a 
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plurality of play sequences which are combined in a pre- 
determined order. As shown in Fig. 59, a play sequence 
comprises any arbitrary number ol play lists, A play list 
describes any arbitrary numbers of play ilems corre- 
sponding to predetermined times (time stamps). 
[0184] In the example shown in Fig. 59, play list 1 de- 
scribes play item 1 , play item 2, play item 3, play item 6 
and play item 7 to be played back sequentially one item 
after another. On the other hand, play list 2 describes 
play item 4 to be played back with timing to start from a 
middle of play item 2 and to end at a middle of play item 
3. As for play list 3, play item 5 is to be played back with 
timing to start from a middle of play items 3 and 4 and 
to end at a middle of play item 6. Thus, in an operation 
to play back this play sequence, play item 1, play item 
2, play item 3, play item 6 and play item 7 are played 
back sequentially one item after another and, at the 
same time, play item 4 is played back with timing to start 
from a middle of play item 2 and to end at a middle of 
play item 3 while play item 5 is played back with timing 
to start from a middle of play items 3 and 4 and to end 
at a middle of play item 6. 

[0185] Relations among a program, play sequences 
and play items are summarized into a single diagram 
shown in Fig. 60. In a word, a program comprises any 
arbitrary number of play sequences each composed of 
any arbitrary number of play lists in which each consists 
ol any arbitrary numbers of play items. 
[0186] As described so far, the present invention has 
been exemplified by an application thereof to an optical 
disc apparatus. It. is worth noting, however, that the 
present invention can also be applied to a case in which 
information is recorded onto or played back from other 
types of recording medium. 

[0187] It should be noted that, as a presentation me- 
dium for presenting computer programs to be executed 
to carry out the processing described above to the user, 
communication media such as a network and a satellite 
can be utilized in addition to recording media like a mag- 
netic disc, a CD-ROM and a solid-state memory device. 
[0188] As described above, in the information 
processing apparatus according to the present inven- 
tion, a plurality of pieces of data are controlled by first 
control means on a 1-on-l oasis and any arbitrary 
number of first control means are controlled by a second 
control means, any arbitrary range in which is controlled 
by a third control means. In addition, in the information 
processing method and the presentation medium ac- 
cording to the present invention, any arbitrary number 
of control states at first control steps are controlled at a 
second control step and a control state of any arbitrary 
range at the second control step is controlled at a third 
control step. Furthermore, in the recording medium ac- 
cording to the present invention, as control information, 
first control means, a second control means and a third 
control means are recorded. As a result, editing can be 
carried out with ease in a short period of time. ■ 



Claims 

1. An information processing apparatus comprising: 

5 a first control means for controlling a plurality 

of pieces of data on a t-on-1 basis; 
a second control means tor controlling any ar- 
bitrary number of said first control means; and . 
a third control means for controlling any arbi- 

*0 ■ ■ trary range in said second control means. 

2. An information processing apparatus according, in 
claim 1 characterized in that said second control 
means controls said arbitrary number of said first 

*s control means so that said pieces of data controlled 
by said first control means are played back with at 
least portions of said data overlapping each other 
on a time axis. 

20 3. An information processing apparatus according in 
claim 1 characterized in that said first control means 
is a unit of said data and said third control means is 
a unit of said data seen from a user. 

25 4. An information processing apparatus according in 
claim 1 characterized in that, in a range of said third 
control means or said second control means, a 
seamless operation to play back said data is made 
possible. 

30 

5. An information processing method comprising the 
steps of: 

controlling a plurality of pieces of data on a lon- 
35 1 basis; 

controlling any arbitrary number of control 
states at said first control steps; and 
controlling "a control state of any arbitrary range 
at said second control step. 

40 

6. A presentation medium used for presenting a pro- 
gram for making an information processing appara- 
tus carry out processing comprising: 

45 a first control step of controlling a plurality Of 

. pieces of data on a 1-on-1. basis; 
a second control step of controlling any arbi- 
trary number of control states at said first con- 
trol steps; and 

so a third control step of controlling a control state 

of any arbitrary range at said second control 
step. 

7. A recording medium used for recording data and 
55 control information for controlling said data, said re- 
cording medium characterized in that said control 
information comprises: 



18 



BNSDCCID: <EP 



0917149A2 I > 



35 EP 0 917 149 A2 

a first control means for controlling a plurality 
of pieces of data on a 1-on-1 basis; 
a second control means for controlling any ar- 
bitrary number of said first control means; and 
a third control means for controlling any arbi- 5 
trary range in said second control means. 
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/ VOLUME. TOC 

I 

— ALBUM. STR 

I 

—PROGRAM 
I 

-PR0GRAM_001-PGI 
I 

- PROGRAM 002. PG I 



-PR0GRAM_S$S.PGI 



-TITLE 
I 



-TITLE.001.V0R 

I 

-TITLE_002:VOR 
I 

— TITLE 003. VDR 



-TITLEJM.VDR 



CHUNKGROUP 
I 

— CHUNKGROUP 001.CGIT 
I 

- CHUNKGROUP_002. CG I T 



- CHUNKGROUP_§§§. CG I T 



CHUNK 
I 

— CHUNK OOOLABST 
I 

— CHUNK 0002. ABST 



"I 

— MPEGAV 
I 

-STREAMS-001 

. I I 
I -CHUNK_0001.MPEG2 

I I 

I -CHUNK_0002.MPEG2 

I I 

I —CHUNK 0003.MPEG2 

II 
-STREAMS-002 

I I 

I — CHUNK_001 1 . MPEG2 

I I 

I -CHUNK 0012.MPEG2 

I I 

I : 
I 



-STREAMS 446 
I I 

I — CHUNK_XXXX. MPEG2 



- SCR I PT 



PICTURES 
I 

-TITLE.001. JACKET 
I 

-TITLE 001. THUMB 
I 

— PROGRAM 002- THUMB 



-GRAPHICS 



-CHUNK.mX.ABST 



20 



□Mcrwirv ,cd 



3 

EP0 917 149 A2 



F I 
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2 




• 


Syntax 




Number of 


Bits 


Mnemonic 


VOllME.TOC{ 

file t VDe i d 

volume inf ormat ion 0 
text blockO 

} 


■ 


8*16 




unar [ ioj 

* 

• * 
• 


F 1 


G. 


3 


• 




Syntax 




Number of 


Bits 


Mnemoni c 


vo lume_ inf ormat i on () { 
vol ume_attr ibute 0 
resume 0* 
vo 1 ume_rat i ng 0 
wr i te_protect () 
play_protect 0 
record ing_t imer 0 

i 


F 1 




4 




.t 


Syntax 




• 

Number of 


Bits 


Mnemoni c 


volume_attr ibute 0 { 

. vol ume_attr i bute_l ength 
vdr_vers ion 




32 

4*4 ' 


* 


uimsbf 
bed 

■ 


reserved 

t i t le_pl ayback_mode_f lag 
program_playback_mode_f lag 


« 


6 
1 
1 


* 


bslbf 

bslbf 
bslbf 


vol ume_p lay_t ime 0 
update_t ime_count 0 




. 4*8 
32 




. bed 
uimsbf 


make r_ id 
model_code 




8*16 
8*16 




char[16] 
char[l6] 


POSIO 

} 




32 




bslbf 

* 
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Syntax Number of Bits Mnemonic 

resume 0 { 



resume_length 




u 1 msDT 


reserved 


// for byte alignment 


3 


l_ 1 Li 

bsl bf 


resume swi tch 


1 


bit 


reserved 




4 


bslbf 


number_of_r 


ecords 

• 


4 


uimsbt 


reserved 


// for byte alignment 


7 


bslbf 


resume_auto. 


_execute_t ime_f I ag 


1 


bit 


resume_auto. 


_execute_t ime 0 


4 14 


bed 


reserved 




4 


bslbf 


resume_auto. 


_execute_record_number 


4 


u imsbf 


for (i=0; i<number_of_records; i++) { 


• 




resume. 


mode_f lag 


4 


i lit 
bsl bf 


object. 


type 


4 


bslbf 


I inked_ 


record_number 


4 


u imsbf 


number. 


of_t imes 


16 


1 £. 

u imsbf 


resume. 


updated_t ime 0 


4 14 


bed 


swi tch (ob j ect ty pe) { 


* 


■ 


case 


title: 






• 


title_number 


16 


ii i (n«ihf 


• 


t i t le_local_t ime_stamp 


64 


ii i mcKi 




break; 






case 


program: 








pr og rarrwiumbe r 


16 


u imsbf 




pr ogram_ I oca I _t i me_s tamp 


64 


u i ms b f 




break; 






case 


program_bind: 








p r og r am_b i nd_n urn be r 


16 


uimsbf 




program_order 


16 


u imsbf 




• 

program.n umber 


16 


u imsbf 




program^ I oca I _t i me_stamp 


64 


uimsbf 




break;. 






case 


play, item.: 








P I ay_i tem_number 


16 


uimsbf 




p I ay_i tern. I oca l_t i me_stamp 


64 


u imsbf 


■ 


break 
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Syntax 

volume_rating() { 

vo I ume_rat i ng_l ength 
reserved . 

vo I ume_rat i ng_t ype 



vo I ume_rat i ng_password 
switch (rat i ng_type) { 
case age_limited- 

country_c~ode_f or_rat i ng 
for(i=0;i<32;i++) { 

rat ing_bi t_f or_age_I i mi ted 
break; 
CARA: 

CARA_category 
reserved 
reserved 

b r eak » 

RSAC:. 

RSAC_category . . 
level 
reserved 
break! 



Number of Bits Mnemonic 



} 



} 



case 



case 



32 

6 

2 

128 



32 



4 
4 
16 



4 
4 
16 



u imsbf 

bslbf 

bslbf 

bslbf. 



bslbf 



bslbf 



bslbf 
bslbf 
bslbf 



bs I bf 
bslbf 
bslbf 
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Syntax Number of__Bits Mnemonic 

wr i te_protect 0 { 



wr i te_protect_ I ength 


32 


uimsbf 


vol ume_wr i te_protect_l eve I 


4 


uimsbf 


password_enab I e__f I ag 


1 


bslbf 


append_on I y_f I ag 


1 


bslbf 


exp i rat i on_t i me_enab I e_f I ag 


1 


bslbf 


numbe r_of _t i mes_enab I e_f I ag . 


1 

* 


bslbf 


password_f or_vol ume.wr i te_protect 


128 


bs 1 bf 


reserved 


8 


bs 1 bf 


wr i te_protec t_se t_t i me () 


56 


bed 


reserved 


8 


bslbf 


wr i te_protect_exp i rat i on_t ime 0 


56 


bed 


number_of _t imes 


16 


u imsbf 
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Syntax _. _ ^ Number of t^s ^ Mnemoni c 

pTay_protect 0 f 



P I ay_protect_ length 


32 


uimsbf 


vo I ume_p I ay_protect_f I ag 


2 


bslbf 


reserved 


2 


bslbf 


password_enab I e_f I ag 


1 


bslbf 


reserved 


1 ' 


;: bslbf 


exp i rat i on_t i me^enab I e_f I ag 


1 


bslbf 


numbe r_of _t i mes_enab I e_f I ag 

■ 


1 


bslbf 

■ 


password_f o r_vo I ume_p I ay_pr otec t 


128 


" bslbf 


reserved 


8 


bslbf 


play_protect_set_time () 


56 


bed 


reserved 


8 


bslbf 


pi ay_protect_expi rat ion_t ime 0 


56 . 


bed 


number_of_t imes 


16 


uimsbf 



) 



F I G . 9 



Syntax __ Number of _Bj t_s _Mnemoni_c 

record i ng_t imer 



record tng_t imer_length 
record ing_timer_f lag 
riumber_of _entry 

for ( i=0; i<number_of_entry ; r++) { 
date_and_t ime 
channel 

program 

} ' 

} 



BNSOOCIO: <E P Q 91714SA2 I > 
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F I G : 10 



Syntax 

text>.lock() { 

text_block_l ength 
nurhbe r_of _ I anguage_set s 
number_of_text_i terns 

for(i=0; i<number_of_language_sets; { 
language_set 0 

} 

for(i=0; i <number_of_text_i terns; i++) { 
text_item() 

) 

} 



Number of Bits Mnemonic 



32 
8 

16 



uimsbf 
uimsbf 
uimsbf 



FIG. II 



Syntax 

language_set 0 { 
reserved 
language_code 
character_se.t_type 
number_of _l anguage_set_names 
for (i=0l i <number^of_language_set_names; i++) {- 
character_set_type_f o rename 
language_set_name_l ength 

language_set_name 8* I anguage_set_name_ length 



Number of Bits Mnemonic 



8 


bslbf 


24 


bslbf 


8 


bslbf 


8 


uimsbf 


8 


bslbf . 


8 


uimsbf 




bslbf 



} 



} 
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Syntax 



Number of Bits Mnemonic 



16 

16 

16 

8 

8 



8 
4 
16 
I ength 



uimsbf 
u imsbf 
uimsbf 
bslbf 
uimsbf 



text_item() { 

text_i tem_l ength 
text_i tem_id 
text i tern sub_jd 
f I ag s . 

■ number_o'f_used_l anguage_sets 
//loop for each language set 
for (i=0l i<number_of_used_language_setsI i++) { 
language_set_i d 
reserved 

text_str i ng_l ength 

text_string 8*text_st r i ng. 

b i tmap 0 

} 

stuff i ng_bytes 



uimsbf 
bslbf 
uimsbf 
bslbf 



8*n bslbf 



} 





F 1 


1 G . 13 




Syntax 




• Number of. 8its 


Mnemon i c 


ALBUM. STR {' 

f i le_type_id 
a 1 bum 0 
text blockO 

1 




8*16 


char(16] 
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Syntax 
a I bum () 



Number of Bits Mnemonic 



( 



albuiaj ength 

reserved 

volume_status 

if (vol ume_status== " lb 

chief volume f I ag 
) else { 

reserved 

} ' 



'■) I 



{ 



if (vol ume_status~ "lb" ) 

if (chief_volume_f lag== "lb" ) { 
reserved 
album_type 
albim_id 

number_of__d iscs_in_al bum 
numbe r_of _vo I umes_ i n_a I bum 

for (i<l;i<number_of_volumes_i-n_albunwi++) { 
d i sc_ i d_f or_a I bumjnembe r 
volume_id_for_al bumjnember 
tit le_offset_number 

} 

reserved_forj>rogram_bind 

number_of _program_b i nds 

for (i=0;i<number_of_program_binds; { 

numbe r_of _p rog ram_ i n_t h i s_p rog ram_b i nd 
for (i=0; i<number_of_programs_i n_thi s_ 
• di sc_id^for_program_bi nd_member 
vo I ume_ i d_f or_program_b i nd jnembe r 
program_number 



32 



uimsbf 



}else{ 



} 



//chief_volume_f lag— "Ob 



chief_disc_id 
chief_volume_»d 
(a I bum J d 



6 


bslbf 


1 


bslbf 


1 


bslbf 


1 




6 


• 

• 

bslbf 


2 


bslbf 


128 


bslbf 


16 


u i msbf 


16 


u i ms bf 


I CO 


OS i OT 


1 28 


bs 1 bf 


16 


uimsbf 


8 


bslbf 


8 


uimsbf 


16 


ui msbf 


program 


bind;i++) ( 


128 


' uimsbf 


128 


uimsbf 


16 

* * 


uimsbf 


128 


uimsbf 


128 


u i msbf 


128 


bslbf 
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Syntax 

iniijm' VDR{ 

f i le_type_id 
title.infoO 
text block 0 

} 



Number of Bits 



8*16 



Mnemonic 



char [16] 



F I G . 16 



title_info() { 

t i t le_info_length 
f lags_for_t it le 
eg i t_f i le_id 

t i 1 1 e_start_chunk_group_t ime_ stamp 
t i 1 1 e_end_chunk_g roup_t i me_stamp 

t i 1 1 e_p I ay back_t i me 0 

reserved 

number_of _marks 

for (i=0. i <number_of ...marks', i++) { 
reserved 
mark_type 

mark_chunk_group_t ime_stamp 



) 



} 

stuff i ng_bytes 



Bits 


Mnemonic 


32 


u imsbf 


32 


bslbf 


16 


uimsbf 


64 


uimsbf 


64 


u imsbf 


32 


bed 


32 


bslbf 


16 


uimsbf 

* 


4 


bslbf 


4 


bs I bf 


64 


uimsbf 


8*n 


bslbf 



• 

F I G . 17 


Syntax 


Number of Bits 


Mnemonic 


PROGRAM_$$$.PGI ( 
f i I e_type_id 
program 0 
text blockO 

} 


8*16 


* 

char[16] - 



091 71 49 A2 l> 
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Syntax _ f 

programO { 

program_length 
f lags_f or_program 
program_status 
program_pl ayback_t ime.O . 
reserved 

numbe r_of _p I ay_sequences 
for ( j =0 1 j<number_of _p lay_sequence \ j++) { 
number_of_play_l ists 
for (k=0:k<number_of_play_l.i sts;k++) { 
p lay_l i st_start__t i me_stamp_of f set 
p lay_l i st (k) 

) 



of Bits 


Mnemon i c 


32 


uimsbf 


32 


bslbf 


4 


bslbf 


32 


bed 


32 


bslbf 


16 


uimsbf 


16 


uimsbf 


64 


uimsbf 



} 



} 

stuff i ng_bytes 



8*n 



bslbf 



F I G. 19 



Number of Bits Mnemonic 



Syntax^ 
play_l i st 0 { 

//playback sequence of play items in this play list 
numbe r_of _p I ay_i terns 16 
for (k=0;k<number_of_play_i terns ;k++) { 

pJ ay_i tem_number 16 
reserved ^ 31 

seam I ess_connect i on_f I ag 1 

} . 

//play_i tem_table 

for (P IN=1 ;PIN<=number_of_play - i tems - in_program;PIN++) { 
play_item(). 

} 

I 



u imsbf 

uimsbf . 

bslbf 

bslbf 
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Syntax 

play_i temO { 

play_i tem_ length 
play_i tem_type 
playjriode 

total_playback_t ime() 

■ 

menu_i tem_number 
return_i tem_number 
next_i tem_number 
prev_i tem_number 

if (play_item_type= "0000b" ) { 
//play item for one "cut" 
t i t I e_numbe r 
//IN point 

i tem_start_t ime_stanip 

//OUT point 

i tem_end_t i me^stamp 



Number of Bits 



Mnemon i c 



} 



} 



32 

8 

8 

32 

16 
16 
16 
16 



16 



64 



64 



uimsbf 
bslbf 
bslbf 
bed 

uimsbf 
uimsbf 
uimsbf 
u imsbf 



uimsbf 
uimsbf 



uimsbf 



F I G. 2 I 



Syntax 

CHUNKGROUP_##i. C6IK 
f i I e_type_id 



Number of Bits 



Mnemon i c 



chunkgroup_t *me_base_f lags 
chunkgroup_t ime_base_of f set 

chunk_connect i on_i nf o() 
text blockO 



8*16 

32 
64 



char [16] 

bslbf 
uimsbf 



31 
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Syntax Number of Bits Mnemonic 

chunk_connect ion_inf o 0 { 



. chunk_connec t i on_ i nf o_ I ength 


32 


u i msbf 


reserved. 


16 


bslbf 


number_of_chunks 


16 


uimsbf 


chunk__sync_p lay_f lag 


8 


bslbf 


// chunk info file list 






for( i =0» i <number_of_chunks; i +■+).{ 







c hun k_a r r an geme n t_ i n f o () 

} 





F 


1 G. 2 


!3 


Syntax 






Number of Bits Mnemonic 



chunk_arrangement_info() { 



chunk_ar rangement_ i nf o_ 1 ength 


32 


uimsbf 


chunk_inf o_f i le_Jd 


16 


bslbf 


reserved 


5 


bslbf 


chunk_swi tch_stream_id 


16 


bslbf 


pre sentat i on_start__cg_t i me_count 


64 


uimsbf 


pre sentat ion_end_cg_t ime_count 


64 


uimsbf 


reserved 


4 


bslbf 


chunk_t i me_c oun t_t ype 


4 


bslbf 


number_of _start_or ig i nal_t ime_count_extens i on 


8 


uimsbf 


number_of _end_o r i g i na 1 _t i me_count_extens i on 


8 


uimsbf 


// presentation start position and time 






presentat i on_start_or i g i na 1 _t ime_count 


64 


uimsbf 


presentat ion_end_orig ina I _t ime_count 


64 


uimsbf 



for < i =0; j <number_of _start_or i g r na I _t i me_count_extens i on ; j++) 

tc_ext_attri botes 16 bslbf 

start_original_time_count_extension 64 uimsbf 



// presentation end position and time 

for (k=0l k<nunber_of _end_or i g i na I _t i me^count_ex tens i on ; k++) ( 

to_,ext_attributes 16 bslbf 

end_or igi na I _t i me_count_ex tens ion 64 u imsbf 

} 

transition infoO 



32 

■ 
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Syntax . 

chunk1xxxx.a*bst{ 

f i le_type_id 
reserved 
chunk_f i le_id 
info_type 
//stream_info() 

if (info_type== - MPEG2_SystemJV ) { 
number_of_programs 

else { 

number_of_programs 

} 

for (i=0.; i < numb er_of_prog rams; i++H 
numb e r _of _s t r earns 

for ( "i=0; i <number_of_str earns; i++) { 
stream_ident i f ier 



//slot type information 

reserved 

slot_uni t_type 

if (slot_uni t_type== "t ime^stamp" ) { 
slot_time_ length 

} else { 

reserved 

} 

number_of _s I ots 
reserved 

swi tch(info_type) { 
case MPEGl_System: 
case MPEG2_System_PS: 
case MPEG2_System_TS: 
case video_elementary stream 

numbe r_o.f _ I _p i c t u r es__ i n_s I o t 

break; 

default*. 

reserved 

break; 

i 



Number of Bits . Mnemonic 



//stream attribute 
ES.attributeO 



//loop of slot info 

for ( i=0; i<number_of .streams.; i++) ( 

for ( i=0; i<number_of_slots; { 
slot_info () 

) 

) 



8 16 
4 
16 
4 



8 
8 

8 
16 

4 
4 

32 

32 

32 
4 



char [163 
bslbf 
uimsbf 
bslbf 



uimsbf 
~0000 0001 

uimsbf 
bslbf 

bslbf 
bslbf 

uimsbf 

bslbf .• 

uimsbf 
bslbf 



uimsbf 



bslbf 
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o 
a: 

\- 

o 
o 



LU 
I- 
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VOLUME. TOC 
ALBUM. STR 
PROGRAM 

— PROGRAM_001 . PGI 
TITLE 

— TITLE_001. VOR 
-TITLE_J)02. VOR 
— TITLE_003. VOR 

CHUNKGROUP 

-CHUNKGROUP__001. CGIT 

-CHUNKGR0UP_002.CGIT 



CHUNK 

— CHUNK 
— CHUNK 
— CHUNK 



0001 . ABST 

001 1. ABST 

0012. ABST 



MPEGAV 

— STREAMS_001 
I . . —CHUNK. 

I • 

— STREAMS_002 
I —CHUNK 
| —CHUNK 



0001. MPEG2 



001 1. MPEG2 

0012. MPEG2 
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F I G . 27 



PROGRAM 



TITLE 




CHUNKGROUP 



CHUNK 



STREAM 



001 ; 


002 


\l \ 


i ■ \t 


001 






* • 

000 1 



1 




003 



0001 



I 002 


M 




001 1 


001 2 


I 

0 

00 1 1 


1 

0 

0012 



F I G. 




.chunkgroup_t ime 
base offset 



chunkgroup_t ime_ 
base offset +A 



B 



chunkg roup_t i me_ 
base_offset4-A + B . 



CHUNK-GROUP 
TIME . 



CHUNK001 1 




CHUNK001 2 . 
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FIG. 29 



/ MPEGAV 

I -STREAMS.003 

I I -CHUNK 0031.MPEG2 



F I G . 30 



/ VOLUME. TOC 

-ALBUM. STR 
-PROGRAM 

I -PR0GRAM_OO1.PGI 
-TITLE 

I -T I TLE_001 . VDR 
I • -T I TLE_002. VDR 
I -TITLE.003. VOR 
I -TITLE.004. VDR* 

-CHUNKGROUP 

I -CHUNKGR0UP_O01.CGIT 
I -CHUNKGR0UP_O02.CGIT 
I -CHUNKGROUP_003.CGIT* 

-CHUNK 

I -CHUNK_0001. ABST 
I -CHUNK_001 1 . ABST 
I -CHUNK_001 2. ABST 
I -CHUNK_0031 . ABST * 

-MPEGAV 

I -STREAMS.001 

I | -CHUNK_0001 . MPEG2 

I I 

I -STREAMS.002 

I L _-CHUNK_001 1 . MPEG2 

I I -CHUNK_001 2. MPEG2 

I J 

I -STREAMS 003* 

I | -CHUNK 0031. MPEG2* 
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PROGRAM 




TITLE 



GHUNKGROUP 



001 



CHUNK 



STREAM 



002 



001 



0001 



1 




0001 



0 03 


t \ 


004 






002 


003 




i \i 


001 1 


0012 


003 1 





0011 0012 




003 1 
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MPEGAV 

I -STREAMS.002 

I | -CHUNK_0031.MPEG2 



F I G . 33 



-VOLUME. TOC 
-ALBUM. STR 
-PROGRAM 

I -PR0GRAM_001.PGI 
-TITLE 

I -TITLE_001. VOR 
I -TITLE.002. VOR 
I -T ITLE_003. VOR 
I -T I TLE_004. VOR* 

-CHUNKGROUP 

I -CHUNKGROUP 001". CG IT 
I -CHUNKGR0UP_002.CGIT 

-CHUNK 

I -CHUNK^OOOl.ABST 
| -CHUNKjOOll.ABST 
I -CHUNK_001 2. ABST 
| -CHUNK_0031.ABST* 

-MPEGAV 

I -STREAMS.001 

I -CHUNK.OOOI. MPEG2 

I 

-STREAMS_002 
I -CHUNK_0011.MPEG2 
-CHUNK 0012- MPEG2 
-CHUNK_0031.MPEG2* 
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PROGRAM 




TITLE 



CHUNKGROUP 



CHUNK 



STREAM 



001 



000 1 




000 1 



001 


002 

« 


i > 





V V 



003 


v 




> 


002 


V 




) 


001 1 


.0012 


003 1 


I 

Q 

001 1 


I 

G 

0012 


.1 

Q 

0031 
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F I G.35 



PROGRAM 




TITLE 


00 1 


002 








CHUNKGROUP 


001 




'■ : — - 


CHUNK 


\ 0001 



V V 



STREAM 



G 

0001 



003 


004 


v v 


002 




00 1 1 


00 1 2 


I 

G 

00 11 i 


Q 

00 12 



• 
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field name 


value 


f i 1 e_type_i d 


"TITLEJNFO.OOOOO" 



F I G. 37 



mark_type 


* • 

Meaning , 


0000b 


index type 1 


0001b 


index type 2 


0010b. .0111b 


index type 3.- index type 8 


1000b 


skip IN 


1001b 


skip OUT 


1010b 


jump to title end or next title 


1011b 


scene .change 


1100b 

■ 


aud i o mute 


1101b 


audio peak 


1110b 


picture still 


1111b 


reserved 



index ■• direct entry point in the title 
skip IN : start point of title skip 
skip OUT : end point of title skip 



* • • 



43 



BNSDOCID: <EP. 



Q917149A2J_> 



EP0 917 149 A2 



F I G. 38 



TITLE 



001 



CHUNKGROUP 



CHUNK 



I 



STREAM 



V 



001 



0001 



0002 | 

\ 



V 





0001 0002 
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Q. 

e 

cd 

JZ 

CO £ 



03 



X 

cd 



<u 







/ 








co 








E 














CO 
CD 


CL 












CO 








O 










l_ 




























cd 










CD 




o 
















o 








CO 























CD 

ro 



CL 

co 



CO 



to 



CD 



5* 



CD 



O 
L_ 



X 
CD 



CD 



3 

O 



CD 



CD 



CO 
CD 



CO 



CD 
CD 



e 

cO 

CO 
CD 



CD 



O 



V 



X 
CD 



CD 



v. -»-» 











CO 


CO 


Ol 


a 


c. 








CO 


CO 


E 





CD 







CD 






CO 


e 




cd 


CD 


CD 












CO 






i £ 




CO 




CD 




U 








CO 




-*-> 


» 
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field name 


va I ue 


f i I e_type_i d 


"CHUNKGR0UP_OOG(T 



F I G . 4 I 



chunk_sync_p I ay_f I ag 


Meaning 


Ob 


play only one chunk at the same time 


1b 


need to play chunks simultaneously 



F I G . 42 



or i g i na I _t i me_count_type 


Mean i ng 


0000 


MPEG2 System time stamp (90kHz) 


000 1 


SMPTE timecode 


0010 


field (525/60) (59. 94Hz) 


0011 


field (625/50) 


0100 


frame (525/60) (29. 97Hz) 


0101 


frame (625/50) 


0110 


drop frame time code(525/60) 


0111 


non drop frame time code (525/60) 


1000 


60Hz 

* 


1001 


50Hz 


1010 


24Hz 


1011 


second 


1 1 00. . 1 1 1 1 


reserved 
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field name. 


value 


f i I e_t ype_ i d 


"STREAM. I NFOJJOOO" 



F I G. 44 



f i I e_type 


Mean i ng 


0000 


MPEG2_System_PS 


0001 


MPEG2^System_TS 


0010 


MPEG2_System_PES 


001 1 


v i deo_e I ementar.y_s t ream 


0100 


e I ementary_st ream_except_v i d:eo 


0101 


MPEG 1 _Sy sternest ream 


0110 


reserved 


011 1 


reserved 


1000 


Consumer_DVC 


1001 .. 1111 


reserved 
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s I ot_un i t_type 


Meaning 


0000b 


' t i me_stamp' : time stamp value 


0001b 


'GOP': one GOPCGroup of pictures) 


00 1 0b 


aud i o_f rame' one audio frame 


001 1b. . 11 Tib 


reserved 



F I 6. 46 



field name 


va t ue 


f i 1 e_type i d 


" PROGRAM, INF0_000" 



F I G. 47 



program_status Mean i ng 



0000b 


none 


0001b 


or i g i na 1 


00 1 0 b 


copy 


0011b 


preview 


0100b 


rehearsal 


0101b 


temporary 


0110b 


complete 


0111b 


broken 

* 


1000b 


ed i t i ng 


1001b 


backup 


1001b .. 1111b 


reserved 
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TITLE SPLITTING 
PROCESSING START 




V 



ISSUE A COMMAND 
ON A SPLIT POINT 



SI 



CREATE AN INFORMATION FILE FOR 
STORING A 1 ST TITLE WITH THE 
START POINT OF THE SPLIT TITLE 
USED AS A START POINT AND THE 
SPLIT POINT USED AS AN END POINT 



CREATE AN INFORMATION FILE FOR 
STORING A 2ND TITLE WITH THE SPLIT 
POINT USED AS A START POINT AND 
THE END POINT OF THE SPLIT TITLE 
USED AS AN END POINT 



S3 



CHANGE THE NAME OF 
A TITLE FOLLOWING 
THE SPLIT TITLE 



c 



S4 



V 



END 
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PROGRAM 



TITLE 



CHUNKGROUP 




CHUNK 



001 


002 


003 


* 

v \ 


t * 


t v 


■ 001 




0001 







STREAM 




0001 



004 



002 



001 1 



0012 





0011 0012 x 



F I G . 50 

f TITLE SWAPPING PROCESSING START) 



SI 1 



CHANGE 


THE 


NAME 


OF 


ORIGINAL 


TITLE 


2 


TO X 


• 


t 






S12 


CHANGE 


THE 


NAME 


OF 


ORIGINAL 


TITLE 


3 


TO 2 







CHANGE TITLE X TO TITLE 3 




f 



S13 



( end) 
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